Re: dpkg 1.15.6 is slow as hell
On Fri, Mar 12, 2010 at 10:19:50AM +0100, Raphael Hertzog wrote:
> Removing the single fsync() added in tarobject() completely restores the
> original performance. Adding a single sync() after the whole unpack has
> way less impact (1 or 2 seconds more).
>
> diff --git a/src/archives.c b/src/archives.c
> index ab10d19..69110c1 100644
> --- a/src/archives.c
> +++ b/src/archives.c
> @@ -660,8 +660,6 @@ int tarobject(struct TarInfo *ti) {
> am=(nifd->namenode->statoverride ? nifd->namenode->statoverride->mode : ti->Mode) & ~S_IFMT;
> if (fchmod(fd,am))
> ohshite(_("error setting permissions of `%.255s'"),ti->Name);
> - if (fsync(fd))
> - ohshite(_("unable to sync file '%.255s'"), ti->Name);
> pop_cleanup(ehflag_normaltidy); /* fd= open(fnamenewvb.buf) */
> if (close(fd))
> ohshite(_("error closing/writing `%.255s'"),ti->Name);
> diff --git a/src/processarc.c b/src/processarc.c
> index 627bbd2..decf93d 100644
> --- a/src/processarc.c
> +++ b/src/processarc.c
> @@ -637,6 +637,7 @@ void process_archive(const char *filename) {
> close(p1[0]);
> p1[0] = -1;
> subproc_wait_check(c1, BACKEND " --fsys-tarfile", PROCPIPE);
> + sync();
>
> if (oldversionstatus == stat_halfinstalled || oldversionstatus == stat_unpacked) {
> /* Packages that were in `installed' and `postinstfailed' have been reduced
Of course the disadvantage of that is that the rename() is no longer
necessarily atomic on filesystems that don't implement rename() as a
barrier (e.g. ext4 without data=ordered). But these filesystems are
stupid. :-) I think that the above makes sense; otherwise, we're caught
between a rock and a hard place, and this seems the best compromise.
> 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.
I think that is in fact often true of fsync() as well, despite what its
interface might lead one to believe.
--
Colin Watson [cjwatson@debian.org]
Reply to: