[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CD sizes again (and BoF reminder!)

brian m. carlson wrote:
> On Sat, Jul 21, 2012 at 09:25:50PM +0300, Uoti Urpala wrote:
> > So at least in this case the biggest performance problem by far is the
> > inappropriate use of fsync() or other disk synchronization primitives,
> > and CPU use for unpacking is pretty much irrelevant.
> My understanding is that dpkg uses fsync properly; that is, to guarantee
> the data is on the disk before exiting or doing things that require that
> data to be present.  I don't currently see any bugs on dpkg that

There are no things that would "require that data to be present" on disk
in the middle of a dpkg invocation. There may be write ordering
requirements if you want to guarantee some type of consistency after a
crash, and there are AFAIK still no good functions to express such
requirements in Linux (though I haven't checked recently); but it's
important to understand the difference - the "data is on physical disk"
semantics of fsync() are NEVER what you want within a dpkg run.

Whatever the semantics are when using dpkg on a running system, all
attempts to ensure on-disk consistency are wrong for installer and
cdebootstrap use. If the machine crashes in the middle of installation
or debootstrap directory creation, I'm not going to attempt continuing
the operation from where it stopped, so on-disk consistency of the
partial installation is worthless. And as the timings show, you can
speed up installation by more than a factor of 5 by skipping the useless
disk waits (I verified that's still true even if you add moving the
directory to a persistent filesystem and then running sync after the
tmpfs installation).

Reply to: