[systemd-devel] Antw: [EXT] Re: [systemd‑devel] systemd‑nspawn container not starting on RHEL9.0

[Ulrich Windl]

>>> Lennart Poettering <lennart at poettering.net> schrieb am 10.08.2022 um 22:09
in
Nachricht <YvQQhcDJw9aIbgxc at gardel-login>:
> 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‑availa
> ble‑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.

Not true: For SUSE /home is typically using XFS, and we use it with SLES for
(huge) database filesystems.

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