Project

General

Profile

Actions

Bug #40101

closed

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

Added by Nathan Fish almost 5 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
% 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 (v1):
Crash signature (v2):

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 2 (0 open2 closed)

Copied to CephFS - Backport #40442: mimic: libcephfs: returns ESTALE to nfs-ganesha's FSAL_CEPH when operating on .snap directoryResolvedNathan CutlerActions
Copied to CephFS - Backport #40443: nautilus: libcephfs: returns ESTALE to nfs-ganesha's FSAL_CEPH when operating on .snap directoryResolvedPrashant DActions
Actions #1

Updated by Patrick Donnelly almost 5 years ago

  • Project changed from Ceph to CephFS
  • 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
Actions #2

Updated by Nathan Fish almost 5 years 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.

Actions #3

Updated by Zheng Yan almost 5 years ago

  • Status changed from New to Fix Under Review
  • Assignee deleted (Zheng Yan)
  • Pull request ID set to 28545
Actions #4

Updated by Patrick Donnelly almost 5 years ago

  • Status changed from Fix Under Review to Pending Backport
  • Assignee set to Zheng Yan
  • Component(FS) cephfs.pyx added
  • Labels (FS) snapshots added
Actions #5

Updated by Nathan Cutler almost 5 years ago

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

Updated by Nathan Cutler almost 5 years ago

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

Updated by Nathan Cutler over 4 years 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".

Actions

Also available in: Atom PDF