On Wed, Feb 10, 2021 at 03:10:45PM +0100, Balint Reczey wrote: > Source: apt > Version: > Severity: wishlist > > Hi, > > I run eatmydata apt ... frequently and it is used widely by others > when there is no need to fsync()-s during package installations or > removals, but it is nice to save time and wear off SSDs later. > > Using fsync() is unlikely to bring any benefit when a system is very > unlikely to crash or it is cheap to recreate in case of an > installation failure like it is the case for provisioning containers. > Also using fsync is fairly pointless when apt-btrfs-snapshot is > installed and a snapshot is taken after the apt operation anyway. > > Ideally dpkg would provide a command line option for skipping fsync, > but it is not yet the case: #923423. > > On APT's side I'd like to propose a config option which when set would > prefix dpkg calls with eatmydata until dpkg has a better interface for > disabling fsyncs.
dpkg already has --force-unsafe-io to avoid syncs, it's what I use. I don't want to have an option for eatmydata inside apt, it also affects a lot of other stuff down the line like services outside on sysvinit systems and all stuff happening in maintainer scripts; but then it only works on the native architecture, not for foreign ones, and scripts might be unsetting LD_PRELOAD. Heck APT probably should unset LD_PRELOAD like it cleans up PATH. I considered adding a seccomp filter to apt that would block fsync() and friends, which is more persuasive than eatmydata. But force-unsafe-io is usually enough. Lastly, you can also just create a dpkg -> eatmydata symlink somewhere, and then specify that as your Dir::Bin::dpkg, and that would work too. eatmydata could ship some symlinks in /usr/libexec/eatmydata, similar to what ccache does. I do not believe that adding such a hack to apt is the right approach. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en