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" <pa...@poluan.info> wrote: > >> >> On Aug 14, 2012 11:42 PM, "Helmut Jarausch" <jarau...@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.
