Re: dpkg 1.15.6 is slow as hell
On Fri, 2010-03-12 at 23:04:18 +0100, Raphael Hertzog wrote:
> On Fri, 12 Mar 2010, Guillem Jover wrote:
> > Neither of those are good replacements, as the fsync() must be done before
> > the rename(), as we want the guarantee that there's always a valid file in
> > place in case of a crash, either the old or the new, which dpkg should be
> > able to discern and roll-back if needed on reexecution.
> > Doing a sync afterwards might only guarantee the package is not wrongly
> > marked as properly installed if there's a system crash, but that's it.
> That's what matters IMO.
Well, it's probably better than nothing, but I don't think it's the
> > And in such case there's a high probability the files will be
> > zero-length, which would be pretty bad for example Essential packages.
> So let's do the fsync only for essential packages? It's a good compromise
I thought about that also, but it would need to do that for all of the
pseudo-essential set too by checking if the package is a dependency
(direct or indirect) of any of the Essential ones. It would be cheaper
and easier to just fsync() for priority required ones though. But then
neither of those cover packages as important as the kernel, the boot
loader or the file system fsck, to name a few, which might render the
> > In addition POSIX does not guarantee sync() will wait until the writes
> > have finished (only Linux seems to be doing that though).
> True, not sure what other systems are doing though.
I checked GNU/Hurd and GNU/kFreeBSD were dpkg is used as a native
package manager, and on both sync() does not wait. I don't know about
OpenSolaris, Darwin, and others.
- freebsd/sys/kern/vfs_syscalls.c:sync(): Passes MNT_NOWAIT as flags.
For GNU/Hurd, it can be changed by setting the file system translator
fsysopts to --sync, but that's a global setting for all I/O operations:
- glibc/sysdeps/mach/hurd/sync.c:sync(): Passes 0 as wait argument.