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

[Ulrich Windl]

>>> Neal Gompa <ngompa13 at gmail.com> schrieb am 11.08.2022 um 09:22 in
Nachricht
<CAEg-Je9rU+Oo8a_ROEdnM+zruVphwhE9kL31E0bstSavDa1yUg at mail.gmail.com>:
> On Thu, Aug 11, 2022 at 3:15 AM Ulrich Windl
> <Ulrich.Windl at rz.uni-regensburg.de> wrote:
>>
>> >>> 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/htm

> l‑
>>
>> >
>> 
>
single/managing_file_systems/index#the‑xfs‑file‑system_assembly_overview‑of‑a
> vaila
>> > 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.
>>
> 
> In openSUSE, this hasn't been the default behavior for a while. SLES
> will catch up here eventually.

Accidentially I created some filesystems using "yast2 disk" in SLES15 SP4
(latest updates) today:
There the default for any "data" filesystems is (still) XFS (while OS uses
BtrFS).
Agreed, if you don't have a separate filesystem for /home, it'll be a BtrFS
subvolume ("fill one, you fill all", I don't like the subvolume concept, or I
didn't understand the benefits)

Regards,
Ulrich

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