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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
