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

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 

> * 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: