[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How git performs when you throw all of Debian at it

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:

> 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

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 Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: