[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