Project

General

Profile

Actions

Feature #48991

closed

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

Added by Jeff Layton about 3 years ago. Updated almost 3 years ago.

Status:
Resolved
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 3 (0 open3 closed)

Copied to CephFS - Backport #49512: pacific: client: allow looking up snapped inodes by inode number+snapid tupleResolvedPatrick DonnellyActions
Copied to CephFS - Backport #49513: octopus: client: allow looking up snapped inodes by inode number+snapid tupleResolvedNathan CutlerActions
Copied to CephFS - Backport #49514: nautilus: client: allow looking up snapped inodes by inode number+snapid tupleResolvedNathan CutlerActions
Actions #1

Updated by Douglas Fuller about 3 years ago

  • Assignee set to Jeff Layton
Actions #2

Updated by Jeff Layton about 3 years 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?

Actions #3

Updated by Patrick Donnelly about 3 years 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
Actions #4

Updated by Patrick Donnelly about 3 years 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
Actions #5

Updated by Backport Bot about 3 years ago

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

Updated by Backport Bot about 3 years ago

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

Updated by Backport Bot about 3 years ago

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

Updated by Loïc Dachary almost 3 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