Re: Speeding up dpkg, a proposal
ext Chow Loong Jin <email@example.com> writes:
> I remember seeing there being some list of files to be fsynced in one of the
> older dpkgs. It's probably that which led to the ext4 slowdown [...]
Hmm, performance is the ultimate reason for doing all this, but right
now, I am mostly interested in whether my changes are correct. I know
that they improve performance, but I am not totally convinced that they
are actually correct in the way that they change the status of packages,
I am only proposing to add this as an option to dpkg, not to make it the
We might enable it in Harmattan, if I have the balls and it does in fact
speed things up enough, but nothing of that is certain right now. We
might get the improvement we need just from reducing our number of
packages to something reasonable.
>> But then again, I would argue that the sync() is actually necessary
>> always, for correct semantics: You also want to sync everything that the
>> postinst script has done before recording that a package is fully
> Yes, you're right. I completely forgot about that. I don't think most postinst
> scripts sync when done. I suppose the best that can be done is to batch the
> stuff as best as can be done to reduce the number of sync()s needed.
On the other hand, it _is_ the job of the maintainerscripts to sync if
that s necessary for correctness, and maybe we don't want to take that
reponsibility away from them.
And in the big picture, all we need is some guarantee that renames are
comitted in order, and after the content of the file that is being
renamed. I have the impression that all reasonable filesystems give
that guarantee now, no?