Re: CD sizes again (and BoF reminder!)
On Mon, 23 Jul 2012, Adam Borowski <kilobyte@angband.pl> wrote:
> You tested ext4. On btrfs, dpkg is around an order of magnitude slower,
> making using it without eatmydata a laughable idea.
>
> And that's on a filesystem whose features include:
> * transactions (so all dpkg processing could be done without a single
> fsync)
How would it do that? Presumably we need some dpkg changes to get that
result.
> * writeable snapshots (if you happen to get a power loss right
> during an untransacted dpkg run with eatmydata, all you need is a [re]boot
> with subvol=my_last_checkpoint)
How would we do that? Make a snapshot and modify the boot loader
configuration before the installation and then fix the boot loader afterwards?
Also if you have a separate filesystem for /usr or if a postinst script does
something to /var on a separate filesystem then using a snapshot might not get
the result you desire. Of course you could snapshot other filesystems (as
long as /var doesn't happen to contain a live database or something else you
don't want to lose).
I don't think we can easily solve these problems automatically unless we can
put some BTRFS specific code in dpkg.
I agree that it would be good to have a configuration option to have dpkg not
call sync, the data integrity of a system is the responsibility of the
sysadmin and we should respect their choices.
As an aside, I haven't had a serious problem with BTRFS root yet. I've got
one system that's been running wheezy for a couple of weeks and there haven't
been any updates that have been big enough to be a problem.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Reply to: