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

[Neal Gompa]

On Wed, Aug 10, 2022 at 11:16 AM 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."
>
> 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...
>

You could also ask Red Hat to consider adding Btrfs to RHEL and give
them your use-case so that they could consider adding it. It's already
used by default in Fedora and many other distributions, so bringing it
back to RHEL at this point would be a matter of customers asking for
it.


-- 
真実はいつも一つ！/ Always, there's only one truth!