On Friday 29 June 2007 03:15, Raphael Hertzog <[EMAIL PROTECTED]> wrote: > > Below is part of the output of stracing dpkg when installing a package. > > As you can see it opens the file without O_SYNC and renames it without > > calling fsync() first. This means that a reboot during the period for > > which write- back caching is active (which depends on the load of the > > machine, the amount of free RAM, and the filesystem in use) will cause > > loss of file data. > > If the machine reboots while dpkg unpacks a package, dpkg will know that > the package is not cleanly unpacked/updated and this will simply get fixed > later after the reboot when the user finishes his update.
You are assuming that the dpkg status files are always committed to disk AFTER the various package files that dpkg writes. There is no guarantee that it will happen that way. The fact that fsync() is called on files under /var/lib/dpkg after the package files have been written means nothing. The best behaviour for a filesystem that is designed for performance is to have fsync() not give the same result as sync(). > I fail to see a scenario where this behaviour leads to a problem. > > If the .dpkg-new file is not written on disk, I don't see why the > directory content would be updated on disk. Directory contents may be updated before file data, and often are. It seems that most filesystems nowadays in a default configuration will journal meta-data but not file data. The journal is generally written much faster than the rest of the disk (it's a small contiguous area in a fast part of the disk) so the condition of having meta-data updated before file data is not uncommon. I've just spent some time debugging a SUSE system that was hit by this bug. Please explain why you think that the practice of writing files without calling fsync() (the defined API for ensuring that data is written to disk) would work for dpkg when it has been observed to fail for rpm. Also what reason is there for not calling fsync()? Performance will be lower, but is such performance really such a problem for modern systems that it's worth decreasing reliability to gain performance? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
