[LU-9537] implement "lfs getstripe --fid" for directory FIDs Created: 19/May/17  Updated: 31/Jan/22  Resolved: 02/Jun/21

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: Lustre 2.15.0

Type: Improvement Priority: Minor
Reporter: Andreas Dilger Assignee: Yoann Valeri
Resolution: Fixed Votes: 0
Labels: easy

Issue Links:
Related
is related to LU-15504 "lfs find" is missing "-ls" support Open
is related to LU-9629 lfs migrate does not work as a non-ro... Resolved
is related to LU-10378 "lfs find" is missing "-printf" support Resolved
is related to LU-10705 add "blocks" support to "lfs find" Resolved
Rank (Obsolete): 9223372036854775807

 Description   

The "lfs getstripe --fid" option (-F) was implemented to extract the FID from the LOV EA of a regular file during processing, since this information was already available. However, this does not work for directories since the default layout LOV EA they store does not contain the FID, even though it would be consistent with other getstripe options.



 Comments   
Comment by Yoann Valeri [ 11/May/21 ]

Hello,

This is my first try at contributing to Lustre code, and I need some help regarding the source code. From what I understand of the description, there are two parts to modify: the printing of the fid regarding directories, and the assignment of a proper fid to directories when created.

I think I managed to find what to modify for the first part. I think I have to go lustre/utils/liblustreapi.c, line , and remove the "is_dir" condition.

However, I am struggling for the second part, as I can't find if I have to simply remove a similar "is_dir" condition somewhere, or if it is a complete modification of behaviour when creating directories. In both cases, I can't find the proper places to touch...

If anybody has any tips or could provide any help, let me know.

Comment by Andreas Dilger [ 11/May/21 ]

Hello Yoann,
thank you for looking into this issue. This ticket is only concerning the first issue you mention (printing of the directory FID). The second issue you describe (assignment of a proper FID to the directory at creation time) is a non-issue (clients have assigned directory FIDs at creation time since Lustre 2.0).

I don't think that just removing "is_dir" from the printing code is going to solve this issue, since the mechanism that the client uses to print the FID for regular files just does not work for directories. However, the client can already get the FID for a directory using a different mechanism in "lfs path2fid <directory>" (calling llapi_fd2fid() internally on the directory file descriptor), so it would be straight forward to hook that into "lfs getstripe --fid" to make it transparent to the user, even if the underlying mechanism is different for directories.

Comment by Gerrit Updater [ 17/May/21 ]

Yoann VALERI (yoann.valeri@cea.fr) uploaded a new patch: https://review.whamcloud.com/43714
Subject: LU-9537 utils: implement "lfs getstripe --fid" for directories
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: f05f63220cfce76627f112b1b81b517287dd8bc0

Comment by Yoann Valeri [ 19/May/21 ]

Hello,

As it is currently standing, the patch has been approved by two people, but there are bugs unrelated to my modifications (namely a bug with sanity-pfl.sh on group review-dne-part-4 (revis-212vm9), associated to the ticket LU-13724, and another bug with ost-pools on group review-dne-zfs-part-2 (trevis-25vm1), associated to the ticket LU-14456 and LU-12830). 

I associated both bugs in the corresponding test failure page with their Jira tickets, but I am unsure about what to do now. On the Lustre wiki for submitting changes, it is said that I should "Retest any sessions that failed with known issues", however I cannot find any way to retrigger test failed tests (and I am unsure if that would change the end result...).

Uploading a new patchset seems strange to me, but maybe that is what is wanted ?

Comment by Andreas Dilger [ 19/May/21 ]

Hello valeri, it is possible to retrigger failed test sessions for intermittent test failures unrelated to the patch, with sufficient permissions. I've already done this for you, but due to recent changes in our test environment it has not posted anything to the patch in Gerrit that the tests are running again.

Comment by Yoann Valeri [ 25/May/21 ]

As of now, the patch has two +1 and passes the tests.

From what I understand from the "submitting changes" page on the wiki, the Gatekeeper was notified of the patch, and is working with it, so there is no need to add a +2 on the patch ?  Or will it be given when the Gatekeeper approves the patch ?

Comment by Andreas Dilger [ 25/May/21 ]

valeri, you are correct. Once there are two Code-Review: +1/+2 reviews, and Verified: +1 from Maloo and Jenkins, then the patch automatically becomes a candidate for master-next. When the current master-next is landed, a new master-next branch is made about once a week from all the patches that are ready for landing. The timing depends on whether there are test failures in the current master-next, and how difficult it is to isolate/eject the patch causing the problem, as well as whether your patch conflicts with other patches already in that branch, among other things Priority is given to bug fixes over features if there are conflicts, but I don't expect an issue with this patch. The Gatekeeper will mark the patch +2 and land it once it has passed integtation testing. If there is no update in the next 2-3 weeks, then feel free to ask here or on the patch to get some attention on it.

Comment by Gerrit Updater [ 02/Jun/21 ]

Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/43714/
Subject: LU-9537 utils: implement "lfs getstripe --fid" for directories
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: b57c88fe4b70392ca915c18e51d50ce90256ba69

Comment by Peter Jones [ 02/Jun/21 ]

Landed for 2.15 - congratulations valeri

Generated at Sat Feb 10 02:27:03 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.