On Thu, Aug 11, 2022 at 3:15 AM Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote: > > >>> Lennart Poettering <lennart@xxxxxxxxxxxxxx> schrieb am 10.08.2022 um 22:09 > in > Nachricht <YvQQhcDJw9aIbgxc@gardel-login>: > > On Mi, 10.08.22 10:13, Thomas Archambault (toma@xxxxxxxxxxxxxxxxx) 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. > In openSUSE, this hasn't been the default behavior for a while. SLES will catch up here eventually. -- 真実はいつも一つ!/ Always, there's only one truth!