virtio-fs simply passes through stat’s st_ino field from the host. When sharing a directory with submounts, (because st_dev cannot be passed through) this may lead to multiple distinct inodes (on different devices) having the same st_dev/st_ino combination in the guest. Steps to Reproduce: 1. Share a directory with a submount. Confirm that on the host, files in the root of the directory and in the submount have a different st_dev. 2. Mount the directory in the guest. 3. Look up st_dev for those same files in the guest. Actual results: In the guest, st_dev for all files of one share are the same. Expected results: Every submount should have a distinct st_dev, so the combination of st_dev and st_ino is always unique. Additional info: Alternatively, we could try to not directly pass through st_ino from the host and instead invent our own persistent and unique 64-bit IDs. But this does not seem feasible.
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
This BZ now depends on BZ 1941613, because we need kernel support in the guest for this. On the virtiofsd side, the necessary changes have been implemented in commits 9c6ac04363^..9d82f6a3e6 and f26688a91, all of which are in the qemu 5.2 release. Max
Upstream feature already present in qemu-6.0. Marked as TestOnly and moved directly to ON_QA Set ITR=18 to get release+, the dependent kernel bug 1941613 is already ON_QA w/ ITR=14
Verify this bug in the following pkg Host: qemu-kvm-6.0.0-18.module+el8.5.0+11243+5269aaa1.x86_64 kernel-4.18.0-310.el8.x86_64 Guest: kernel-4.18.0-310.el8.x86_64 Steps: 1.mount nfs to host #mount 10.66.8.134:/home/nfs on /home/nfs_c 2.using /home as the shared dir for virtiofsd #/usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu1 -o source=/home/ -o announce_submounts 3.boot up rhel8.5.0 vm and mount with virtiofs (guest)# mount -t virtiofs myfs_11 /mnt/vfs/ 4.check file's st_dev/st_ino in root directory and submount directory from host >>> os.stat('/home/test1') os.stat_result(st_mode=33188, st_ino=410443, st_dev=64770, st_nlink=1, st_uid=0, st_gid=0, st_size=4, st_atime=1623288367, st_mtime=1623288367, st_ctime=1623288367) >>> os.stat('/home/nfs_c/test2') os.stat_result(st_mode=33188, st_ino=25821219, st_dev=51, st_nlink=1, st_uid=0, st_gid=0, st_size=10, st_atime=1619158194, st_mtime=1619158194, st_ctime=1619158194) 5.check them from guest >>> os.stat('/mnt/vfs/test1') os.stat_result(st_mode=33188, st_ino=410443, st_dev=47, st_nlink=1, st_uid=0, st_gid=0, st_size=4, st_atime=1623288367, st_mtime=1623288367, st_ctime=1623288367) >>> os.stat('/mnt/vfs/nfs_c/test2') os.stat_result(st_mode=33188, st_ino=25821219, st_dev=50, st_nlink=1, st_uid=0, st_gid=0, st_size=10, st_atime=1619158194, st_mtime=1619158194, st_ctime=1619158194) st_dev id is not the same for every submount which is correct.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (virt:av bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:4684