Project

General

Profile

Feature #48991

client: allow looking up snapped inodes by inode number+snapid tuple

Added by Jeff Layton about 1 month ago. Updated 3 days ago.

Status:
Pending Backport
Priority:
Normal
Assignee:
Category:
-
Target version:
% Done:

0%

Source:
Development
Tags:
Backport:
pacific,octopus,nautilus
Reviewed:
Affected Versions:
Component(FS):
Client, Ganesha FSAL, libcephfs
Labels (FS):
Pull request ID:

Description

Currently, we have ceph_ll_lookup_inode(), but that only takes an inode number and can't deal with a snapped inode. Add a new lookup function to libcephfs that allows you to look up snapped or non-snapped inodes by inode number and snapid.

This is necessary to allow ganesha to work properly when dealing with snapped inodes.


Related issues

Copied to CephFS - Backport #49512: pacific: client: allow looking up snapped inodes by inode number+snapid tuple New
Copied to CephFS - Backport #49513: octopus: client: allow looking up snapped inodes by inode number+snapid tuple New
Copied to CephFS - Backport #49514: nautilus: client: allow looking up snapped inodes by inode number+snapid tuple New

History

#1 Updated by Douglas Fuller 29 days ago

  • Assignee set to Jeff Layton

#2 Updated by Jeff Layton 28 days ago

I started looking at this today, and it's a little trickier than I thought. The current client code that sends the LOOKUPINO request (_lookup_ino) always just leaves the snapid field zeroed out (AFAICT).

The corresponding handler on the MDS (Server::handle_client_lookup_ino), seems to rely on that though:

  if ((uint64_t)req->head.args.lookupino.snapid > 0)
    return _lookup_snap_ino(mdr);

That condition is weird, in that "snapid" is le64, so this is effectively casting that to u64 (regardless of host endianness), and the if statement just a check to see whether that value != 0. CEPH_NOSNAP, however is defined as (__u64)-2, which will evaluate as being >0 in the above conditional.

It's not clear why this is testing for 0 instead of CEPH_NOSNAP. I guess I need to understand why CEPH_NOSNAP is -2 and not 0. What is the special significance of snapid being 0 in the if condition in Server::handle_client_lookup_ino?

#3 Updated by Patrick Donnelly 12 days ago

  • Status changed from New to Fix Under Review
  • Target version set to v17.0.0
  • Source set to Development
  • Backport set to pacific,octopus,nautilus
  • Pull request ID set to 39294

#4 Updated by Patrick Donnelly 3 days ago

  • Tracker changed from Bug to Feature
  • Subject changed from allow looking up snapped inodes by inode number+snapid tuple to client: allow looking up snapped inodes by inode number+snapid tuple
  • Status changed from Fix Under Review to Pending Backport
  • Component(FS) Client added

#5 Updated by Backport Bot 3 days ago

  • Copied to Backport #49512: pacific: client: allow looking up snapped inodes by inode number+snapid tuple added

#6 Updated by Backport Bot 3 days ago

  • Copied to Backport #49513: octopus: client: allow looking up snapped inodes by inode number+snapid tuple added

#7 Updated by Backport Bot 3 days ago

  • Copied to Backport #49514: nautilus: client: allow looking up snapped inodes by inode number+snapid tuple added

Also available in: Atom PDF