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