Details

    • Technical task
    • Resolution: Fixed
    • Major
    • Lustre 2.4.0
    • Lustre 2.3.0
    • None
    • 4062

    Description

      During the LU-812 patch series to implement Linux 3.0 client support for Lustre, lustre_mount() was changed to remove the struct vfsmnt argument that was previously available to lustre_get_sb(). The lack of struct vfsmnt argument complicates the ability to re-export the Lustre client filesystem via NFS, due to the BUG_ON(!mnt) in dentry_open().

      It seems rather unfortunate/unfair that the default get_name() function is passed the "mnt" argument, while the filesystem-specific get_name() is not. I don't know if this is due to technical or ideological reasons.

      The simplest fix would would be to see if we can get a patch submitted upstream and to SLES SP3 to pass the "mnt" argument to the ->get_name() method, but this may hit objections and would take time in any case.

      Another way to fix this, as btrfs_get_name() and gfs2_get_name() have done, is to implement the name lookup part of the code internally, without using the VFS readdir() code to do it. This is considerably more complex, since it would mean duplicating or refactoring ll_readdir(), ll_get_dir_page(), and ll_dir_readpage() to avoid the use of filp/file arguments so that it can be called directly from ll_get_name().

      A major hack would be to stash the vfsmnt from some function like ll_getattr into sbi->ll_mnt, but this has the danger that the vfsmnt might change during runtime without Lustre being notified of it.

      Attachments

        Issue Links

          Activity

            [LU-1718] fix Lustre NFS re-export for 3.0+ kernels
            pjones Peter Jones added a comment -

            James we track those differently

            pjones Peter Jones added a comment - James we track those differently

            Their is still a patch outstanding for b2_1

            simmonsja James A Simmons added a comment - Their is still a patch outstanding for b2_1
            pjones Peter Jones added a comment -

            Landed for 2.4

            pjones Peter Jones added a comment - Landed for 2.4

            James, I think you should make your NFS patch dependent on the LU-812 patch for b2_1 as is. As far as I can see your patch is only needed if and when http://review.whamcloud.com/#change,3661 is accepted and merged.

            bogl Bob Glossman (Inactive) added a comment - James, I think you should make your NFS patch dependent on the LU-812 patch for b2_1 as is. As far as I can see your patch is only needed if and when http://review.whamcloud.com/#change,3661 is accepted and merged.

            I have a patch ready for NFS export testing for Lustre 2.1. The question is should http://review.whamcloud.com/#change,3661 be redone without the NFS disable part in llite_lib.c
            and I submit my patch for this part or should I make my NFS patch dependent on the LU-812 patch for b2_1 as is?

            simmonsja James A Simmons added a comment - I have a patch ready for NFS export testing for Lustre 2.1. The question is should http://review.whamcloud.com/#change,3661 be redone without the NFS disable part in llite_lib.c and I submit my patch for this part or should I make my NFS patch dependent on the LU-812 patch for b2_1 as is?

            Patch updated for master.

            simmonsja James A Simmons added a comment - Patch updated for master.

            Okay this is a rough first patch, http://review.whamcloud.com/#change,3624. Most likely I missed some thing so feel free to tear it apart.

            simmonsja James A Simmons added a comment - Okay this is a rough first patch, http://review.whamcloud.com/#change,3624 . Most likely I missed some thing so feel free to tear it apart.

            I also thought about the hack of storing ll_mnt from some other function. Looking at the code it doesn't look to bad to refactor it much like btrfs and gfs2 does it. I have a patch I'm doing basic testing to right now that I can post soon.

            simmonsja James A Simmons added a comment - I also thought about the hack of storing ll_mnt from some other function. Looking at the code it doesn't look to bad to refactor it much like btrfs and gfs2 does it. I have a patch I'm doing basic testing to right now that I can post soon.

            Actual change introducing this problem is http://review.whamcloud.com/1951, since there are several patches landing under LU-812.

            adilger Andreas Dilger added a comment - Actual change introducing this problem is http://review.whamcloud.com/1951 , since there are several patches landing under LU-812 .

            People

              wc-triage WC Triage
              adilger Andreas Dilger
              Votes:
              0 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: