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