Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-9537

implement "lfs getstripe --fid" for directory FIDs

Details

    • Improvement
    • Resolution: Fixed
    • Minor
    • Lustre 2.15.0
    • 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

            [LU-9537] implement "lfs getstripe --fid" for directory FIDs
            pjones Peter Jones added a comment -

            Landed for 2.15 - congratulations valeri

            pjones Peter Jones added a comment - Landed for 2.15 - congratulations valeri

            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

            gerrit Gerrit Updater added a comment - 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
            adilger Andreas Dilger added a comment - - edited

            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.

            adilger Andreas Dilger added a comment - - edited 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.
            valeri Yoann Valeri added a comment -

            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 ?

            valeri Yoann Valeri added a comment - 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.

            adilger Andreas Dilger added a comment - 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.
            valeri Yoann Valeri added a comment -

            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 ?

            valeri Yoann Valeri added a comment - 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

            gerrit Gerrit Updater added a comment - 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.

            adilger Andreas Dilger added a comment - 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.
            valeri Yoann Valeri added a comment -

            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 Yoann Valeri added a comment - 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.

            People

              valeri Yoann Valeri
              adilger Andreas Dilger
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: