Re: systemd-nspawn container not starting on RHEL9.0

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mi, 10.08.22 10:13, Thomas Archambault (toma@xxxxxxxxxxxxxxxxx) wrote:

> Thank you again Lennart, and thx Kevin.
>
> That makes total sense, and accounts for the application's high level
> start-up delay which appears to be what we are stuck with if we are over
> xfs. Unfortunately, it's difficult to dictate to the client to change their
> fs type, consequently we can't develop / ship a tool with that baseline
> latency on our primary target platform (RHEL xx.)
>
> So the next obvious question would be, is XFS reflink support on the
> systemd-nspawn roadmap or actually, (and even better) has support been
> incorporated already in the latest and greatest src and I'm just behind the
> curve working with the older version of nspawn as shipped in RHEL90?
>
> I'm asking because according to the RHEL 9 docs (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/managing_file_systems/index#the-xfs-file-system_assembly_overview-of-available-file-systems)
> it's the current default fs and is configured for "Reflink-based file
> copies."

We issue copy_file_range() syscall, which should do reflinks on xfs,
if it supports that. Question is if your kernel supports that too. I
have no experience with xfs though, no idea how xfs hooked up reflink
initially. And we never tested that really. I don't think outside RHEL
many people use xfs.

If you provide a more complete strace output, you should see the
copy_file_range() stuff there.

Lennart

--
Lennart Poettering, Berlin