vfs_ceph_new: Fix inode resolution inside vfs_ceph_ll_walk and vfs_ceph_iget
Here we try to fix the inode resolution logic used in the following 2 wrappers:
- vfs_ceph_ll_walk()
ceph_ll_walk() API is expected to operate relative to the current working directory(cwd). But the wrapper itself had a strict check for cwd causing any absolute path(which may include cwd) to be handed in directly to the underlying ceph_ll_walk() API. At times it can result in ENOENT
depending on the current working directory. Instead we could progressively check for the presence of cwd in the path components and make it relative to cwd providing a trimmed version of the incoming path. For example with cwd = /foo/bar, previously we used to get ENOENT
for an incoming path /foo/bar/shift.txt. Now /foo/bar/shift.txt is trimmed to /shift.txt which can be successfully resolved using ceph_ll_walk() API.
- vfs_ceph_iget()
Internally CephFS snapshots(as directories) share the same inode number with its parent. Thus an attempt to lookup a particular snapshot can end up resolving the parent where snapshot specific xattr(ceph.snap.btime) might not be present. This is crucial for finding snapshots when vfs_ceph_snapshots module is stacked with vfs_ceph_new. Considering the special case of snapshots we avoid doing lookup based on inode number but proper name component to successfully process requests. See below for an example taken from commit message:
path (ino = 3)
|
--- dir (ino = 4)
|
--- .snap (ino = 3)
|
--- snap1 (ino = 3)
|
--- dir (ino = 4)
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15818
Checklist
-
Commits have Signed-off-by:
with name/author being identical to the commit author -
(optional) This MR is just one part towards a larger feature. -
(optional, if backport required) Bugzilla bug filed and BUG:
tag added -
Test suite updated with functionality tests -
Test suite updated with negative tests -
Documentation updated -
CI timeout is 3h or higher (see Settings/CICD/General pipelines/ Timeout)
Reviewer's checklist:
-
There is a test suite reasonably covering new functionality or modifications -
Function naming, parameters, return values, types, etc., are consistent and according to README.Coding.md
-
This feature/change has adequate documentation added -
No obvious mistakes in the code