From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 6837B1381F4 for ; Tue, 14 Aug 2012 17:24:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 403E6E08AF; Tue, 14 Aug 2012 17:24:04 +0000 (UTC) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by pigeon.gentoo.org (Postfix) with ESMTP id A2D90E0899 for ; Tue, 14 Aug 2012 17:21:36 +0000 (UTC) Received: by qaas11 with SMTP id s11so2033569qaa.19 for ; Tue, 14 Aug 2012 10:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=YIekjjxTCP2/4du0Wl6oirdwZh+ZkJFl0QGEGlF2UBY=; b=wy5bIAtKrzDFivJr/XouKd4tN2M4U9slCGjNRsCA34SgquywiK+tXA5hSUK2KH/i8p d4aXUBDu1griz4gBFJZJsRhWROl47NXWQrHN5u/Fl4wsxTBxDvbotNUeYD1H1CglzEn+ GDovpIUheuIt/Z2TZtIHNkO1F/jm0AFjaRwPyg54pD9wJAKIS3hSDEr5g/5OqFKrBB3u UN1dxcTocGsiUoHsn/0ztCHhCEzmQi48Mca1Xol7/rJMZu6ic+YqIR51fcHch1pAtKF1 9vwpfzZ3rsowzr8DBmdHDrPD1XiJRdIfI0MfyVUGy4OWiBc84JlCjV+abfK9C4dWX8Pw EI4w== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.224.176.197 with SMTP id bf5mr34626137qab.41.1344964895963; Tue, 14 Aug 2012 10:21:35 -0700 (PDT) Received: by 10.49.37.228 with HTTP; Tue, 14 Aug 2012 10:21:35 -0700 (PDT) Received: by 10.49.37.228 with HTTP; Tue, 14 Aug 2012 10:21:35 -0700 (PDT) In-Reply-To: References: <1344962187.18169.0@numa-i> Date: Tue, 14 Aug 2012 13:21:35 -0400 Message-ID: Subject: Re: [gentoo-user] Fast file system for cache directory with lot's of files From: Jason Weisberger To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=20cf302d4d62dbfbd704c73d0a53 X-Archives-Salt: 223a371e-0476-43b4-ba9b-46555402648e X-Archives-Hash: b25471f4387469ed336e9b2602bfa062 --20cf302d4d62dbfbd704c73d0a53 Content-Type: text/plain; charset=ISO-8859-1 Sure, but wouldn't compression make write operations slower? And isn't he looking for performance? On Aug 14, 2012 1:14 PM, "Pandu Poluan" wrote: > > On Aug 14, 2012 11:42 PM, "Helmut Jarausch" > wrote: > > > > On 08/14/2012 04:07:39 AM, Adam Carter wrote: > >> > >> > I think btrfs probably is meant to provide a lot of the modern > >> > features like reiser4 or xfs > >> > >> Unfortunately btrfs is still generally slower than ext4 for example. > >> Checkout http://openbenchmarking.org/, eg > >> http://openbenchmarking.org/s/ext4%20btrfs > >> > >> The OS will use any spare RAM for disk caching, so if there's not much > >> else running on that box, most of your content will be served from > >> RAM. It may be that whatever fs you choose wont make that much of a > >> difference anyways. > >> > > > > If one can run a recent kernel (3.5.x) btrfs seems quite stable (It's > used by some distribution and Oracle for real work) > > Most benchmark don't use compression since other FS can't use it. But > that's unfair. With compression, one needs to read > > much less data (my /usr partition has less than 50% of an ext4 > partition, savings with the root partition are even higher). > > > > I'm using the mount options > compress=lzo,noacl,noatime,autodefrag,space_cache which require a recent > kernel. > > > > I'd give it a try. > > > > Helmut. > > > > Are the support tools for btrfs (fsck, defrag, etc.) already complete? > > If so, I certainly would like to take it out for a spin... > > Rgds, > > --20cf302d4d62dbfbd704c73d0a53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sure, but wouldn't compression make write operations slo= wer?=A0 And isn't he looking for performance?

On Aug 14, 2012 1:14 PM, "Pandu Poluan"= ; <pandu@poluan.info> wrote:=


On Aug 14, 2012 11:42 PM, "Helmut Jarausch" <jarausch@igpm.rwth-aachen.= de> wrote:
>
> On 08/14/2012 04:07:39 AM, Adam Carter wrote:
>>
>> > I think btrfs probably is meant to provide a lot of the moder= n
>> > features like reiser4 or xfs
>>
>> Unfortunately btrfs is still generally slower than ext4 for exampl= e.
>> Checkout http://openbenchmarking.org/, eg
>> http://openbenchmarking.org/s/ext4%20btrfs
>>
>> The OS will use any spare RAM for disk caching, so if there's = not much
>> else running on that box, most of your content will be served from=
>> RAM. It may be that whatever fs you choose wont make that much of = a
>> difference anyways.
>>
>
> If one can run a recent kernel (3.5.x) btrfs seems quite stable (It= 9;s used by some distribution and Oracle for real work)
> Most benchmark don't use compression since other FS can't use = it. But that's unfair. With compression, one needs to read
> much less data (my /usr partition has less than 50% of an ext4 partiti= on, savings with the root partition are even higher).
>
> I'm using the mount options compress=3Dlzo,noacl,noatime,autodefra= g,space_cache which require a recent kernel.
>
> I'd give it a try.
>
> Helmut.
>

Are the support tools for btrfs (fsck, defrag, etc.) already complete?

If so, I certainly would like to take it out for a spin...

Rgds,

--20cf302d4d62dbfbd704c73d0a53--