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