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

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.


Reply to: