Sure, but wouldn't compression make write operations slower? And isn't he looking for performance?
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,