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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
