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

[Thomas Archambault]

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."

I understand that the project supports many distros, but I'm also 
assuming that RHEL would make the list of platforms that the tool should 
run optimally on. So, Is this worth submitting an enhancement request? 
It's certainly not a bug.

We like the feature set of nspawn and want to keep banging on it; 
Probably pushing it into spaces it was not intended for, but that's 
another story, and our issue...

Regards,

-Tom

On 8/10/22 04:47, Lennart Poettering wrote:
>> That's the btrfs subvolume ioctl. It's expected to fail on non-btrfs
>> with ENOTTY, and given you have xfs this is behaving as it should.
>>
>> It then starts copying things manually, which is slow. i.e. it's then
>> basically doing what "cp -a" does.
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Berlin
>>