On Di, 09.08.22 12:40, Thomas Archambault (toma@xxxxxxxxxxxxxxxxx) wrote: > Thank you Lennart for the follow-up. > > There does appear to be mostly filesystem operations prior to my manually > killing nspawn as you suggested. I only let it run about 3 minutes prior to > sending a signal given that the strace output = ~25M. > > One obvious issue is the non-zero return from an ioctl call with the > BTRFS_IOC_SUBVOL_CREATE arg at line 410, in the snippet below from my > RHEL9.0 strace capture; this is occurring right after the initial blast of > debug log messages. I'm trying to get a stack trace for that error > currently. > > > 410-2064 ioctl(5</>, BTRFS_IOC_SUBVOL_CREATE, {fd=0</dev/pts/0>, > name=".#machine.c8578d59f810b73d"}) = -1 ENOTTY (Inappropriate ioctl for > device) 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