Details
-
Improvement
-
Resolution: Fixed
-
Minor
-
None
-
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.
Attachments
Issue Links
Activity
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 ?
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.
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 ?
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
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.
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.
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.