On Sat, Aug 31, 2013 at 12:44:21AM +0100, Ben Hutchings wrote: > > Funny that you ask. What's the usual competitor for ZFS? > > btrfs is included in stock kernels, doesn't take massive amounts of memory, > > and has a different approach to deduplication. > > and is slower than any of its competitors.
time (tar xfa /usr/src/linux-source-3.11-rc4.tar.xz;sync) ext4: 32.002s btrfs: 18.770s (an old spinning disk, just had a failure of my primary one) As Ceph backend: http://ceph.com/uncategorized/argonaut-vs-bobtail-performance-preview/ On the other hand, unless you deal with the fsync madness somehow, dpkg performance is, before kernel 3.5, worse than abysmal, and on 3.5+, merely bad. Yet even on ext4, getting rid of fsync gives a massive speedup, so you want to wrap apt/dpkg with eatmydata where possible[1]. With no fsyncs, btrfs slightly wins. Thus: it depends on your particular usage pattern. With filesystems of so different design principles it's hard to tell which is faster: there are cases when btrfs beats competition by a lot, there are cases where it gets beaten. > > Recent kernels are needed only for race-free deduplication, "cp --reflink" > > works in oldstable. > > Please don't suggest using the squeeze or wheezy version of btrfs in > production. 2.6.32 (squeeze) has serious problems in ENOSPC conditions (up to a panic, but no data loss) and works otherwise, what's the problem with 3.2? Sure, fsync speed-ups from 3.5 and send/receive from 3.6 are good to have, but by no means necessary. Distributions whose commercial support specifically mentions btrfs (Oracle, SUSE) are using 3.0 and 3.1. I second the recommendation to use newer kernels, but I see no reason to discourage using it with wheezy. [Disclaimer: while I use btrfs on a bunch of machines, I never touched its internal RAID, so I can vouch only for single block device use (including hw and md RAID).] [1]. On ext4, this should be at least debootstrap (no data to lose yet) and pbuilder/piuparts (a throw-away chroot). On btrfs using eatmydata on apt is safe even on the host system, albeit not in the default configuration: you'd need snapshots you can roll back to. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130831202231.ga26...@angband.pl
