Re: CUT rolling release debian BUT a cautionary comment
Hi!
On Sun, 2015-03-08 at 03:50:50 +0100, Adam Borowski wrote:
> On Sat, Mar 07, 2015 at 12:38:53PM +0100, David Kalnischkies wrote:
> > If I remember correctly btrfs mostly showed its ugly experimental
> > state by being very slow which is hard to justify in an environment
> > where everyone already complains how slow upgrades are in Debian.
> > Hopefully its better now…
>
> The cause is dpkg doing fsync() after each write, to placate a deficiency in
> traditional filesystems: there's no way to tell them to make a barrier other
> than a full fsync. This is because POSIX provides no API to do so. And
> fsync isn't that bad on a simple filesystems, but horrible on ones that
> provide additional guarantees.
No, the problem was precisely on some of those new filesystems, that
required fsync(2) to not get zero-sized files on abrupt shutdowns, and
at the same time behave(d) in an extremely poor way when confronted with
the requirement they impose on applications:
<https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_is_dpkg_so_slow_when_using_new_filesystems_such_as_btrfs_or_ext4.3F>
> There was some recentish work (kernel 3.5) that greatly reduced the cost of
> fsync, but it's still slower than, say, ext4.
Last time there were benchmarks performed on ext4, even after it was
claimed to have been fixed, it showed it was pretty much suboptimal,
compared to ext3 for example (see the kernel bug referenced in the FAQ
entry).
> Until dpkg gets filesystem transaction support, you can wrap dpkg calls
> with eatmydata: the worst that can happen is that in the case of power
> loss you'll have to issue a rollback manually.
As long as Linux does not have an unified filesystem-independent way
of doing that, I don't see that support coming, the current state is a
mess. You can always use dpkg invoke hooks to perform the snapshots.
Thanks,
Guillem
Reply to: