Re: dpkg 1.15.6 is slow as hell
Colin Watson wrote:
> dpkg requires two things from this part of the code, in this order of
> 1) Unpacked files should contain either the old contents or the new
> contents, never something in between.
> 2) After the state is changed to "unpacked", the files should contain
> the new contents, even after a crash.
> I contend that the second requirement is at least somewhat negotiable,
> since dpkg never used to sync, but obviously it would be nice if we can
> manage it.
> What dpkg does *not* need is:
> 3) After unpacking every file, wait until it has been written to disk.
> But 3) is the principal thing fsync() gives us (modulo problems with
> write caching on disks)! On filesystems that follow what Unix
> applications historically always expected, rename() is sufficient to
> guarantee 1).
Naïve question: could Linux be convinced to expose information (in
sysfs, maybe) about whether a given filesystem treats rename() as a
barrier? I think this would be ideal: dpkg could fsync() for robustness
when unsure (and always for Priority: required packages, maybe), but
rely on traditional rename() semantics when the kernel indicates it is
safe to do so.
This is of course a long-term question; it wouldn’t address the immediate
problem of existing kernels. Still, what do you think?