Raphael Hertzog wrote... > The proper approach is to enhance your testing tools to use "eatmydata" > to really disable all fsync() and not only those of dpkg.
Not a good idea. eatmydata introduces new bugs, #667965 is one that
hit me. It causes some pain in multiarch installations, at least a
lot of noise from ldd. And I cannot think of a good reason why the
actual build scripts should do fsync, at least to a degree where this
visibly degrades performance.
Therefore, having something eatmydata-ish inside dpkg was really
helpful in corner cases like buildd is one.
Now, to propose a workaround for build daemons:
Create a small program that wraps the dpkg call into eatmydata. I did
so and called it dpkg-eatmydata. Written in C for performance reasons,
it's still just
#!/bin/sh
/usr/bin/eatmydata /usr/bin/dpkg $@
A configuration sniplet for apt
$ cat /etc/apt/apt.conf.d/dpkg-eatmydata
Dir::Bin::dpkg "/usr/bin/dpkg-eatmydata";
will cause the build dependency resolver to call that
eatmydata-wrapped dpkg, resulting in the desired speed gain.
Downside: Some binaries called from the maintainer scripts still might
emit ldd warnings. I can live with that.
> --force-unsafe-io has not been meant for those use case at all, it was
> meant for some users to gain back some performance lost on supplementary
> fsync() that have been added to dpkg. It was not meant to disable all
> fsync() and in particular not those on the database.
Since that option doesn't really do what it promises, in my humble
opinion it should be retired some day.
Christoph
signature.asc
Description: Digital signature
