[systemd-devel] systemd-nspawn container not starting on RHEL9.0

[Barry]

> On 10 Aug 2022, at 21:10, Lennart Poettering <lennart at poettering.net> wrote:
> 
> On Mi, 10.08.22 10:13, Thomas Archambault (toma at TPArchambault.com) 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.

Isn’t XFS the default for fedora server?

Barry

> 
> If you provide a more complete strace output, you should see the
> copy_file_range() stuff there.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
>