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:
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.
--
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
Reply to: