On Mon, 23 Jul 2012, Adam Borowski <kilob...@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/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207231030.48469.russ...@coker.com.au
