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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1342976322.3820.68.camel@glyph.nonexistent.invalid