Bug#982461: apt: Please provide a configuration option for disabling fsync()-s
Hi,
Instead of having a separate option I went with Julian's suggestion of
having a dpkg -> eatmydata symlink and using that with Dir::Bin::dpkg.
This will be packaged as apt-eatmydata: https://bugs.debian.org/1091634
APT needs a fix to handle when the symlink goes away, then the package
will be safe to remove:
https://salsa.debian.org/apt-team/apt/-/merge_requests/419
Cheers,
Balint
David Heidelberg <david@ixit.cz> ezt írta (időpont: 2021. szept. 20., H, 20:06):
>
> Hello,
>
> I'd like to support Balint here, since for example on mobile phones and
> tablets, which using eMMC and UFS storages, with limited lifetime it's
> using eatmydata almost requirement, but not all users are aware of the
> option. Would be nice to have simple option which could distributions
> based on Debian (for example Mobian) easily enable and improve speed of
> instalation and durability of eMMCs.
>
> Thank you
> David
>
> On Wed, 10 Feb 2021 15:58:59 +0100 Balint Reczey
> <balint.reczey@canonical.com> wrote:
> > Hi Julian,
> >
> > On Wed, Feb 10, 2021 at 3:23 PM Julian Andres Klode <jak@debian.org>
> wrote:
> > >
> > >
> > > 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.
> >
> > IMO the practice of using eatmydata with is widespread enough to be
> > considered safe (checking for systemd as init), but let's not
> consider
> > if for now.
> >
> > As I see apt does not pass --force-unsafe-io either yet to dpkg and
> > the proposed option could add it:
> >
> > test@debian:~$ sudo strace -ff -ofirefox-install.trace -efsync apt
> > install --reinstall ./firefox_85.0.1-1_amd64.deb
> > ...
> > Processing triggers for gnome-menus (3.36.0-1) ...
> > test@debian:~$ grep fsync firefox-install.trace* | wc -l
>
>
> Best regards
> David Heidelberg
>
Reply to: