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 980681381F4 for ; Tue, 14 Aug 2012 17:12:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E2293E088A; Tue, 14 Aug 2012 17:11:19 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id 27B4CE06D6 for ; Tue, 14 Aug 2012 17:05:46 +0000 (UTC) Received: from mail-vc0-f181.google.com ([209.85.220.181]:45828) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.77) (envelope-from ) id 1T1KYp-0023Lf-Pl for gentoo-user@lists.gentoo.org; Wed, 15 Aug 2012 00:05:43 +0700 Received: by vcbfl17 with SMTP id fl17so624754vcb.40 for ; Tue, 14 Aug 2012 10:05:40 -0700 (PDT) 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.220.152.134 with SMTP id g6mr11066261vcw.10.1344963940344; Tue, 14 Aug 2012 10:05:40 -0700 (PDT) Received: by 10.220.29.13 with HTTP; Tue, 14 Aug 2012 10:05:40 -0700 (PDT) Received: by 10.220.29.13 with HTTP; Tue, 14 Aug 2012 10:05:40 -0700 (PDT) In-Reply-To: <1344962187.18169.0@numa-i> References: <1344962187.18169.0@numa-i> Date: Wed, 15 Aug 2012 00:05:40 +0700 Message-ID: Subject: Re: [gentoo-user] Fast file system for cache directory with lot's of files From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=f46d0434beece664c004c73cd18b X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Archives-Salt: 07e08276-75e5-437a-8f03-ea49907a8925 X-Archives-Hash: 585ec326ec2148983903b45cd8779e62 --f46d0434beece664c004c73cd18b Content-Type: text/plain; charset=UTF-8 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, --f46d0434beece664c004c73cd18b Content-Type: text/html; charset=UTF-8


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 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,

--f46d0434beece664c004c73cd18b--