Re: dpkg 1.15.6 is slow as hell

[Jonathan Nieder <jrnieder@gmail.com>]

Colin Watson wrote:

> dpkg requires two things from this part of the code, in this order of
> importance:
> 
>   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?

Jonathan