Re: dpkg 1.15.6 is slow as hell
On Fri, 12 Mar 2010, Guillem Jover wrote:
> Right, I didn't see much degradation on ext3, or I'd probably would have
> considered doing alternative changes instead. I'll be testing on a
> slower box with ext3 to see how it behaves there though.
My main disk is SSD so I didn't notice immediately either.
> > Other possibility would be to use the loop afterwards to reopen all
> > installed files and call fsync() on them. The disadvantage of sync() is
> > obviously when unrelated disk activity happens in parallel to dpkg, it
> > will have to wait more due to this.
>
> 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.
> 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
IMO.
> 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.
Cheers,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
Reply to: