[andoma]

I believe the correct solution to this problem would be that the installers would snapshot the system, install all packages without any fsync()ing at all, then finally one sync() and remove the snapshot. Optionally keeping snapshots if user want to roll back from a broken upgrade (for whatever reason). Again, as others have written here, btrfs is great if your software plays along with it, otherwise it might not be so great.

[rleigh]

While this is a good idea in theory (and is possible on e.g. FreeBSD with ZFS with boot environments), dpkg can't do this easily. The main problem is that it's possible and supported for the managed files to be placed upon multiple filesystems. Separate /usr, separate /var, separate /usr/share, whatever combination you choose. This means that dpkg needs to force file synchronisation across all mounted filesystems and it can only do this robustly by issuing fsyncs.

When there's only a single filesystem, and that filesystem is btrfs (or ZFS), it should however be possible to optimise this away and delegate everything to the filesystem. But even here, maintainer scripts may issue their own fsyncs as they update their own databases, kernel images or whatever.

[zbentley]

> dpkg needs to force file synchronisation across all mounted filesystems and it can only do this robustly by issuing fsyncs

Not if file-change notifications were supported robustly by dpkg and the kernel (to a lesser extent). Getting to that would, however, require massively restricting the compatible-kernel-versions set of dpkg, and would also probably require undoing some of the more . . . misguided pieces of history with regard to file-change notification systems in Linux.

[rleigh]

I don't think this is correct. File-change notifications wouldn't provide any information which isn't already known. dpkg, after all, is entirely responsible for unpacking the .deb files and doing the file modifications. It's fully aware of what was written, in what order, and when.

The problem is that the system state needs checkpointing for every package state change. It must allow for recovery on failure, termination, abortion or power loss, amongst other scenarios. And the package database must remain in sync with the filesystem state.

When every managed file is on one snapshot-able filesystem, this could be rolled back atomically, and the fsyncs skipped. But as soon as you have a non-snapshot-able filesystem or multiple filesystems in use, the fsyncs can't be skipped.