Re: mv is massively slower on the host rather than in a nspawn chroot, regression somewhere?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/24/22 05:14, Chris Murphy wrote:
On Sun, Jan 23, 2022 at 5:30 PM Robert-André Mauchin <zebob.m@xxxxxxxxx> wrote:

Hi,

So I have an annoying bug that started near the beginnings of F35.
My papirus-icon-theme became very slow to install:
https://bugzilla.redhat.com/show_bug.cgi?id=2029709#c18

During the installation, all the files are copied, then renamed by rpm
(no idea why it works like this).

It works fast in a Mock chroot but incredibly slow on bare metal.

I've done a small test of moving files:

[root@cassini icons]# mkdir test
[root@cassini icons]# for (( i = 0; i < 10000; i++ )) do > test/file_$i;
done
[root@cassini icons]# cd test

On host:

time $(for f in *; do     mv "$f" "${f%}.txt"; done)
real    2m3,500s
user    0m3,966s
sys     2m0,431s

In nspawn container:

<mock-chroot> sh-5.1# time $(for f in *; do     mv "$f" "${f%}.txt"; done)
real    0m6.702s
user    0m4.237s
sys     0m3.344s

Since papirus-icon-theme contains more than 100,000 (small) files, it is
a problem. One minute of waiting is ok, 20 mn is not.

What can cause this? I read that nspawn virtualizes the file system,
could it be file system related on the host? (I use btrfs btw)

Any input welcome!

What file system is being used in each case?


Everything is btrfs.

This is a bit obscure but... cp and mv use reflink=auto. On XFS and
Btrfs this means it'll make reflinks (copies metadata, doesn't
duplicate the data extents) if it can. Falling back to a full copy
(metadata and data extents).

But both the host and the nspawn container are using btrfs?

It might not be possible due to an obscure VFS rule that disallows
reflinks (for reasons I don't understand) when the copy or move
crosses mount point boundaries. This includes bind mounts of
directories. Bind mounts are also what are employed behind the scene
with 'mount -o subvol' mount option on Btrfs, which we use by default
in Fedora Workstation and Cloud Edition, and all the desktop spins.

The nspawn container, I'm not super familiar with how it works. I
think on Btrfs, it will create nested subvolumes, i.e. they are not
mounted with the subvol mount option, hence no mount point boundary.
But on other file systems, I think nspawn creates a loop mounted file
system?


I've got two subvol:

UUID=ee9eec69-8710-4503-b389-e16fcde8a0a5 / btrfs subvol=root,compress=zstd:1 0 0

UUID=d7e21336-6ac6-483a-b4f2-aaeecabd8f1f /home btrfs subvol=home,compress=zstd:1 0 0

but when I do my tests there is no subvol crossing, everything happens on the root subvol?

Thanks for your input.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux