On Sat, 2013-08-31 at 22:22 +0200, Adam Borowski wrote: > 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: http://article.gmane.org/gmane.comp.file-systems.xfs.general/54140 http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=2 > 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? ~/src/d-k/dists/wheezy/linux$ grep -r 'BUG_ON(ret)' fs/btrfs | wc -l 290 So there are still 290 instances where an error will crash the system. Some will be cases where the caller has established a precondition that means the called function can't fail. Surely not all of them, though. (And in 3.11, there are still 100 of these...) Many of the many bug fixes I see cc'd to stable appear to be fixing bugs that exist in 3.2, but due to intervening changes they can't be applied without backporting. No-one's providing the backported versions, so the bugs don't get fixed. > 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. [...] Bet they have lots of backported fixes, though. Ben. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg
Attachment:
signature.asc
Description: This is a digitally signed message part