Hi! On Sun, 2013-05-19 at 15:27:32 +0200, Christoph Biedl wrote: > 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.
If you don't want fsync()s on your buildd then you need to run something like eatmydata, nothing else will give you the performance that you want. More so because the filesystems that require pervasive fsync()s are the ones that will be suffering the most, and they are forcing people to sprinkle fsync()s in their programs, to avoid the common data loss scenarios that they introduced to get the speed boost in exchange for data safety. On those you cannot have both. > Therefore, having something eatmydata-ish inside dpkg was really > helpful in corner cases like buildd is one. Where to plug eatmydata is the buildd admin's choice, or part of the buildd framework, not something that should be provided by dpkg. And as I've suspected all along and as shown by Petter, the database fsync()s are insignificant. > > --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. It does, perhaps the man page is not clear enough, but it was implemented this way on purpose. I'll be updating the man page to make it crystal clear though. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
