Project

General

Profile

Bug #40101

libcephfs: returns ESTALE to nfs-ganesha's FSAL_CEPH when operating on .snap directory

Added by Nathan Fish 5 months ago. Updated 11 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Source:
Community (user)
Tags:
Backport:
nautilus,mimic
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
Ganesha FSAL, cephfs.pyx, libcephfs
Labels (FS):
snapshots
Pull request ID:
Crash signature:

Description

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.


Related issues

Copied to fs - Backport #40442: mimic: libcephfs: returns ESTALE to nfs-ganesha's FSAL_CEPH when operating on .snap directory Resolved
Copied to fs - Backport #40443: nautilus: libcephfs: returns ESTALE to nfs-ganesha's FSAL_CEPH when operating on .snap directory Resolved

History

#1 Updated by Patrick Donnelly 5 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 (05/31/2019)
  • Source set to Community (user)
  • Backport set to nautilus,mimic
  • Component(FS) Ganesha FSAL, libcephfs added

#2 Updated by Nathan Fish 4 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.

#3 Updated by Zheng Yan 4 months ago

  • Status changed from New to Need Review
  • Assignee deleted (Zheng Yan)
  • Pull request ID set to 28545

#4 Updated by Patrick Donnelly 4 months ago

  • Status changed from Need Review to Pending Backport
  • Assignee set to Zheng Yan
  • Component(FS) cephfs.pyx added
  • Labels (FS) snapshots added

#5 Updated by Nathan Cutler 4 months ago

  • Copied to Backport #40442: mimic: libcephfs: returns ESTALE to nfs-ganesha's FSAL_CEPH when operating on .snap directory added

#6 Updated by Nathan Cutler 4 months ago

  • Copied to Backport #40443: nautilus: libcephfs: returns ESTALE to nfs-ganesha's FSAL_CEPH when operating on .snap directory added

#7 Updated by Nathan Cutler 11 days ago

  • Status changed from Pending Backport to Resolved

While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".

Also available in: Atom PDF