Issue
I think I was able to speed up creating a Fedora chroot (dnf --installroot=...) using LD_PRELOAD=/usr/lib64/nosync/nosync.so. But that doesn't seem to help for debootstrap. I think it still uses fsync(), just looking at the performance / disk activity (particularly the "Unpacking" lines). Is there another way?
Solution
The reason LD_PRELOAD doesn't work for debootstrap is probably due to using chroot.
Officially, it looks like this isn't supported at the moment: #700633 - Debootstrap is very slow. Please use eatmydata to fix this. Note the time difference should only be significant if you're forced to work on an old-style spinning disk. There may also be other possible workarounds. LXC caches a minimal debian install. Once you have a minimal install, you can use the Debian eatmydata package to bypass fsync for subsequent package installs.
However if you really need this, it is possible to get an LD_PRELOAD library into the chroot. I was surprised to see the Fedora nosync.so worked in a Debian chroot (i.e. with a foreign, older libc) - I wouldn't consider this a reliable combination.
debootstrap mounts /proc as you would expect, which makes it easy to escape the chroot.
with Fedora nosync
sudo sh -c '
exec 3< /usr/lib64/nosync/nosync.so
LD_PRELOAD=/proc/$$/fd/3 time debootstrap --arch=amd64 --variant=minbase jessie jessie-tree http://ftp.debian.org/debian
'
with Debian eatmydata
sudo sh -c '
exec 3< /usr/lib/x86_64-linux-gnu/libeatmydata.so
LD_PRELOAD=/proc/$$/fd/3 time debootstrap --arch=amd64 --variant=minbase jessie jessie-tree http://ftp.debian.org/debian
'
Results
It saved less than 20 seconds on a SATA SSD, which otherwise took 100 seconds). The main limiting factor in this case appeared to be the CPU (a mobile i5 from 2010).
On a laptop with a hard drive (and an i5 CPU from 2015) it saved 80 seconds, from a starting point of 135 seconds. The same technique is needed/applicable for mkosi. Building a systemd test image, it appeared to save 8 minutes, out of 14.
Answered By - sourcejedi