Use systemd-nspawn --volatile=overlay when not btrfs ?

[kapouer]

This makes a huge performance gain, however i'm only building small packages with nspawn,
and i wonder if that option would exhaust memory when building a much bigger package.

[spanezz]

Uh right, this should really be an option, as it makes a lot of sense in a CI. In theory if one is building large packages one can size up swapspace accordingly

[kapouer]

NB:
one must disable f"--overlay={chroot.chroot_dir}:{self.overlay_dir}:/",
or at least adapt it, to gain from using memory.

[kapouer]

NB2:
The combo --volatile=overlay --read-only allows one to set a higher concurrency than 1 on the gitlab-runner:
systemd-nspawn doesn't lock the "image".

[spanezz]

NB2: The combo --volatile=overlay --read-only allows one to set a higher concurrency than 1 on the gitlab-runner: systemd-nspawn doesn't lock the "image".

That's interesting: systemd-nspawn(1)'s documentation of --read-only says "It is also implied if --volatile= is used", and from that it would look like specifying --read-only would be redundant. You instead observed a change of behaviour compared to just --volatile=overlay?

[kapouer]

If i remember well, without "read-only" the image is locked.

[kapouer]

I'll check again in a few days (i have rebuilds to do soon).

[spanezz]

I've implemented this, turned off by default for now unless enabled setting RAMDISK = True at the beginning of the script.

I added a comment with details about --read-only, to prevent it becoming potential cargo-culting in the future.

I'll leave the issue open until when you do rebuild and can check on it