Re: [gentoo-user] Fast file system for cache directory with lot's of files

[Michael Hampicke <gentoo-user@hadt.biz>]

Am 14.08.2012 19:21, schrieb Jason Weisberger:
> 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" <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 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,
>>
>>
> 

I have enough cpu power at hand for compression, I guess that should not
be the issue. But the cache dir mostly consists of prescaled jpeg
images, so compressing them again would not give me any benefits, speed-
or size-wise.