https://bugzilla.kernel.org/show_bug.cgi?id=15910 --- Comment #6 from Peng Tao <bergwolf@xxxxxxxxx> 2010-05-10 14:24:44 --- On Mon, May 10, 2010 at 10:56 AM, <tytso@xxxxxxx> wrote: >> The problem is, dpkg needs to guarantee the system is always usable, >> and when a crash occurs, say when it's unpacking libc, it's not >> acceptable for dpkg not to fsync() before rename() as it might end >> up with an empty libc.so file, even if it might have marked the >> package as correctly unpacked (wrongly but unknowingly as there's no >> guarantees), which is not true until the changes have been fully >> committed to the file system. > > Why not unpack all of the files as "foo.XXXXXX" (where XXXXXX is a > mkstemp filename template) do a sync call (which in Linux is > synchronous and won't return until all the files have been written), > and only then, rename the files? That's going to be the most fastest > and most efficient way to guarantee safety under Linux; the downside > is that you need to have enough free space to store the old and the > new files in the package simultaneously. But this also is a win, > because it means you don't actually start overwriting files in a > package until you know that the package installation is most likely > going to succeed. (Well, it could fail in the postinstall script, but > at least you don't have to worry about disk full errors.) What about letting fsync() on dir recursively fsync() all files/sub-dirs in the dir? Then apps can unpack package in a temp dir, fsync(), and rename. > > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Thanks, -Bergwolf -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.-- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
