On Wed, Jun 03, 2020 at 11:13:26AM +0200, VÃt Ondruch wrote: > > Dne 02. 06. 20 v 19:26 Richard W.M. Jones napsal(a): > > On Tue, Jun 02, 2020 at 12:44:17PM +0200, Florian Weimer wrote: > >> * Panu Matilainen: > >> > >>> Lets start with the basics: > >>> - is sqlite even involved - it will only be used on rawhide builds if > >>> mock bootstrap is used > >>> - does it make a difference if you override _db_backend to bdb/sqlite > >>> from mock config / cli define > >>> - a reproducer please (eg, what package is considerably slower to > >>> build than before, and by how much) > >> And: Does the difference reproduce when building on tmpfs? > > Good time to say that you can use an NBD loopback to mock-build either > > on a userspace ramdisk or backed by a disk but discarding flush > > requests. The performance is indistinguishable from tmpfs (and much > > more flexible in other ways). I did some benchmarking a couple of > > weeks ago: > > > > https://www.redhat.com/archives/libguestfs/2020-May/msg00053.html > > https://www.redhat.com/archives/libguestfs/2020-May/msg00074.html > > > > Easy set up is: > > > > # rm -f /tmp/sock > > # nbdkit -U /tmp/sock memory 100G > > # nbd-client -b 512 -unix /tmp/sock /dev/nbd0 -connections 4 > > # mkfs.xfs /dev/nbd0 > > # mount /dev/nbd0 /var/lib/mock > > > > or using http://libguestfs.org/nbdkit-tmpdisk-plugin.1.html: > > > > # rm -f /tmp/sock > > # nbdkit -U /tmp/sock tmpdisk size=100G > > # nbd-client -b 512 -unix /tmp/sock /dev/nbd0 -connections 1 > > # mount /dev/nbd0 /var/lib/mock > > > > or (requires bleeding edge nbdkit): > > > > # rm -f /tmp/sock > > # lvcreate -L 100G -n tmp /dev/fedora > > # nbdkit -U /tmp/socket --filter=fua fuamode=discard file /dev/fedora/tmp > > # nbd-client -b 512 -unix /tmp/sock /dev/nbd0 -connections 4 > > # mkfs.xfs /dev/nbd0 > > # mount /dev/nbd0 /var/lib/mock > > > > Rich. > > > > NBD kit is definitely interesting piece of technology, but I think there > is missing quite a bit to be as easy as you say and there is definitely > a lot of missing information, e.g. does the setup persist reboots? It > would be probably more interesting, if it was mock plugin the same way > tmpfs or lvm plugins are. A very fair point - it won't be easy to use until it's a plugin. Currently I'm looking at integrating nbdkit into kubenetes, so I don't really have time to look at mock. In answer to your specific question, does it survive over reboots? Answer in two parts: (1) Not if you just type those commands, but you can set up a systemd unit: http://libguestfs.org/nbdkit-service.1.html I haven't worked out the systemd voodoo to make an NBD filesystem mount itself automatically at boot, although that is undoubtedly possible using a mount unit. Difficult bit will be setting up the dependencies. For the RISC-V Koji builders I'm using nbdkit, but it's "hacked" using /etc/rc.local. (2) Additionally the memory plugin (http://libguestfs.org/nbdkit-memory-plugin.1.html) is a RAM disk, and the tmpdisk plugin (http://libguestfs.org/nbdkit-tmpdisk-plugin.1.html) is intentionally designed to be like a "remote tmpfs". So obviously neither will survive a reboot. That's fine for mock builds. Rich. -- 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
