Re: CD sizes again (and BoF reminder!)
Simon Paillard 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.
>
> Though the kernel will have to sync sooner or later
The normal background writes to disk don't affect performance all that
much. The problem is sync operations that force disk waits before
continuing with the install. Copying the debootstrap directory from
tmpfs to disk after installation took about 6 seconds, whereas doing the
syncs between installation steps added about two minutes to the install
time.
> , I understand debian-installer ask dpkg not to fsync:
> - Run dpkg with --force-unsafe-io during installation; syncing is
This only affects one particular instance of syncing (which I think may
be useless anyway on normal ext4 after write+rename reliability was
improved in kernel commit 7d8f9f7d150dded7b68e61ca6403a1f166fb4edf). It
does not disable ALL disk sync operations in dpkg, like
installer/debootstrap use should.
I tested installing and purging libqt4-dev and some dependencies on ext4
(total 17 packages).
With just force-unsafe-io in dpkg config:
aptitude install libqt4-dev: 16 seconds
aptitude --purge-unused purge libqt4-dev: 14 seconds
eatmydata aptitude install libqt-dev: 4-5 seconds
eatmydata aptitude --purge-unused purge libqt4-dev: 4-5 seconds
So unless this is fixed in dpkg, the installer might want to use
eatmydata...
BTW eatmydata doesn't seem to work with cdebootstrap. I guess it uses
chroot or something in a way which breaks that.
Reply to: