Re: dpkg 1.15.6 is slow as hell
On Sun, Mar 21, 2010 at 10:10:38AM +0100, Guillem Jover wrote:
> On Fri, 2010-03-12 at 20:43:29 +0100, Guillem Jover wrote:
> > On Fri, 12 Mar 2010 15:57:28 +0000, Colin Watson wrote:
> > > I'm worried about the syncing changes though;
> > > apparently they're *really* *really* pessimal on some systems, e.g. ext4
> > > with data=ordered (which considers rename() as a barrier itself so the
> > > fsync() isn't necessary in that configuration). Scott James Remnant
> > > reported that it took over an hour to unpack a linux-headers-* package!
> > A possible solution could be to do the unpack for all files in a package,
> > just leaving the new files as file.dpkg-new, not do either of fsync() or
> > replace, and with one pass afterwads fsync() and do the "atomic" (except
> > for dirs etc) replace. I guess this might improve a bit the situation for
> > packages with lots of files, but not sure how much.
> I implemented this and in my tests with linux-headers-2.6.32-4-common
> (which contains around 2500 files) on ext3 it reduced the installation
> times from 12~ to 5~ seconds (with warm cache).
Isn't the rather massive problem with this that it will mean that
unpacking any package temporarily takes twice as much disk space as the
amount occupied by the package? For large packages this is bound to be
Colin Watson [email@example.com]