[Virtio-fs] [virtiofsd] Issue opened: [traking] Underlay NFS filesystem and silly rename
virtiofs-bot at sinrega.org
virtiofs-bot at sinrega.org
Tue Oct 11 09:23:54 UTC 2022
This issue is just to track of the following silly-rename-related bugs:
- [Bug 2018072](https://bugzilla.redhat.com/show_bug.cgi?id=2018072) -
[virtiofs]NFS/xfstests generic/650 failure -.nfs000000003005d939002af3d4': Device or resource busy
- [Bug 1908490](https://bugzilla.redhat.com/show_bug.cgi?id=1908490) -
[Fujitsu] [virtiofs] NFS/xfstests generic/245 failure - .nfs* files
- [Bug 1990912](https://bugzilla.redhat.com/show_bug.cgi?id=1990912) -
[virtiofs + nfs]cannot remove '/mnt/myfs1/fsstress:xfstest generic/013
- This only happens in the C version of virtiofsd
- [Bug 2127063](https://bugzilla.redhat.com/show_bug.cgi?id=2127063) -
[RHEL8.7] virtio-nfs generic/694 failure: rm: cannot remove '/mnt/test/694': Directory not empty
These cannot be solved in virtiofsd, the solution is to:
- that the NFS server implements OPEN4_RESULT_PRESERVE_UNLINKED, or
server-side silly rename.
- or add fuse support for synchronous forgets
The current workaround is to run virtiofsd with `--inode-file-handles=mandatory`,
but this has its own limitations, for instance, requiring `CAP_DAC_READ_SEARCH`.
More info about silly rename:
- [Server-side silly rename](https://linux-nfs.org/wiki/index.php/Server-side_silly_rename)
- [Linux NFS FAQ](https://nfs.sourceforge.net/)
D2. What is a "silly rename"? Why do these .nfsXXXXX files keep showing up?
---
https://gitlab.com/virtio-fs/virtiofsd/-/issues/61
More information about the Virtio-fs
mailing list