libcephfs: returns ESTALE to nfs-ganesha's FSAL_CEPH when operating on .snap directory
When I make an nfs-ganesha export of a cephfs using FSAL_CEPH, the NFS client receives ESTALE when attempting to stat, ls, cd, etc a .snap directory. The developers on Freenode #nfs-ganesha informed me that ganesha does not issue ESTALE, and only passes it through. Therefore libcephfs is returning file handles to ganesha that expire, and is returning ESTALE when these handles are later used.
While NFS clients are able to access specific snapshots by known names, eg
'ls .snap/1' works, being unable to 'ls' .snap renders this unhelpful for many use cases.
#1 Updated by Patrick Donnelly 9 months ago
- Project changed from Ceph to fs
- Subject changed from libcephfs returns ESTALE to nfs-ganesha's FSAL_CEPH when operating on .snap directory to libcephfs: returns ESTALE to nfs-ganesha's FSAL_CEPH when operating on .snap directory
- Assignee set to Zheng Yan
- Target version set to v15.0.0
- Start date deleted (
- Source set to Community (user)
- Backport set to nautilus,mimic
- Component(FS) Ganesha FSAL, libcephfs added
#2 Updated by Nathan Fish 8 months ago
I have just run into another problem which may be related:
'ls .snap' now hangs for a long time (indefinitely?) and the active MDS has 1 process at 140% CPU, as well as 3 more at 60%,60%,and 10% respectively. I set 'max_mds 2' to see if that would split CPU usage. 'ls .snap' then began completing instantly, but incorrectly. It always prints "ls: reading directory '.snap': Stale file handle", then displays between 0 and 3 copies of each snapshot that should be there, for example 3 copies of '_2019-06-03_000001-0400_weekly_1' are listed.