Project

General

Profile

Bug #46355

client: directory inode can not call release_callback

Added by wei liu 4 months ago. Updated 13 days ago.

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

0%

Source:
Community (dev)
Tags:
Backport:
octopus,nautilus
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
Client, Ganesha FSAL
Labels (FS):
Pull request ID:
Crash signature:

Description

I use Ganesha + CEPH to test release_callback feature, I have merged the relevant modification code:
https://github.com/ceph/ceph/pull/34596
https://github.com/nfs-ganesha/nfs-ganesha/commit/58a9114f6b2c48ffa4a04781bdf1faf3ca914f8d
https://github.com/nfs-ganesha/nfs-ganesha/commit/382966c1ce0298347d26a3d22a7c8988fdcdf1da

the test found that the directory inode could not be released,although it can be released in Ganesha, but it can not call _schedule_ino_release_callback() because its status is pinned.


Related issues

Copied to fs - Backport #46516: octopus: client: directory inode can not call release_callback Resolved
Copied to fs - Backport #46517: nautilus: client: directory inode can not call release_callback Resolved

History

#1 Updated by Patrick Donnelly 4 months ago

  • Status changed from New to Fix Under Review
  • Assignee set to wei liu
  • Target version set to v16.0.0
  • Source set to Community (dev)
  • Backport set to octopus,nautilus
  • Pull request ID set to 35327
  • ceph-qa-suite deleted (fs)
  • Component(FS) Client added

#2 Updated by Patrick Donnelly 3 months ago

  • Status changed from Fix Under Review to Pending Backport

#3 Updated by Nathan Cutler 3 months ago

  • Copied to Backport #46516: octopus: client: directory inode can not call release_callback added

#4 Updated by Nathan Cutler 3 months ago

  • Copied to Backport #46517: nautilus: client: directory inode can not call release_callback added

#6 Updated by Patrick Donnelly 3 months ago

wei liu wrote:

fix:
https://github.com/ceph/ceph/pull/35327

Hi Wei, the PR # is in the issue metadata. No need to leave a comment (it can cause confusion if the PR # changes!).

#7 Updated by Nathan Cutler 13 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