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
