[Libguestfs] RPM package builds backed by nbdkit

[Richard W.M. Jones]

Context:
https://bugzilla.redhat.com/show_bug.cgi?id=1837809#c28
https://rwmj.wordpress.com/2020/03/21/new-nbdkit-remote-tmpfs-tmpdisk-plugin/
http://libguestfs.org/nbdkit-tmpdisk-plugin.1.html
https://github.com/libguestfs/nbdkit/blob/0632acc76bfeb7d70d3eefa42fc842ce6b7be4f8/plugins/tmpdisk/tmpdisk.c#L182

I did a bit of testing to try to see if this is really feasible, and
yes I think it is.  Discussion below, experimental results first ...

I compiled qt5-qtwebkit from Rawhide dist-git by running the
"fedpkg local" command.

Version: qt5-qtwebkit-5.212.0-0.46.alpha4.fc33
Host:    AMD Ryzen 9 3900X 12-Core Processor
Disks:   Fast NVME disks, but using dm-crypt and LVM.

Compiling qtwebkit normally (baseline):     28m19.921s

baseline with nosync enabled:               28m12.67s

nbdkit file plugin backed by a local LV     28m53.259s (baseline + 2%)
over a local Unix domain socket
nbd.ko client (loop mounting) with multi-conn = 4

nbdkit tmpdisk plugin backed by local LV    28m14.151s
over a local Unix domain socket
nbd.ko client (loop mounting) with multi-conn = 1 [note 1]

As you can see there's no appreciable difference in any of the times.
Basically they all take the same time, the overhead of nbdkit + loop
mounting is not significant.

The tmpdisk plugin erases flush/FUA requests (deliberately), which is
similar to but architecturally cleaner than nosync IMHO.  However
nosync makes no difference because it's intended for a different use
case which we are not testing here:
https://github.com/rpm-software-management/mock/wiki/Feature-nosync

Where nbdkit might be useful for Koji builds (we're already using it
for some Fedora/RISC-V builds):

 * Let's you create on-the-fly temporary disks backed by disk or memory.

 * Could be used remotely, eg. if you have builders with small amounts
   of storage, but a fast network and a separate storage server.

 * Could allow you to engineer the crap out of the storage to tune it
   very specifically for builds (dropping FUAs would only be the start
   here).

Rich.

[note 1] tmpdisk doesn't support multi-conn.  This is because it
serves a different, fresh, temporary to each client, so if a single
client connects multiple times they'd see corruption since writes over
one connection would not be seen on other connections.  We do normally
recommend using multi-conn because it can improve performance,
although not in these tests.  However changing tmpdisk to support
multi-conn is architecturally tricky.  You'd have to have a way to
associate client connections to builds (exportname?)

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW