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

Create per-client "export" /proc file on server for each client connection

Details

    • Improvement
    • Resolution: Fixed
    • Minor
    • Lustre 2.11.0
    • None
    • 8412

    Description

      Similar to the "import" file on the client for each client-to-server connection, it would be useful to have a file on the server in the per-client directory obdfilter/*/exports/$NID/export. This would contain export connection information as in the "import" file (connect flags, etc. and also as described in LU-3386).

      Attachments

        Issue Links

          is related to

          Bug - A problem which impairs or prevents the functions of the product. LU-10972 Interop master <-> 2.11.0 sanity test_0d: FAIL export client version

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved
          is related to

          Improvement - An improvement or enhancement to an existing feature or task. LU-8066 Move lustre procfs handling to sysfs and debugfs.

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open

          Improvement - An improvement or enhancement to an existing feature or task. LU-3386 improve osc/mdc "imports" connect data

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Activity

            [LU-3397] Create per-client "export" /proc file on server for each client connection
            pjones Peter Jones added a comment -

            Landed for 2.11

            pjones Peter Jones added a comment - Landed for 2.11
            gerrit Gerrit Updater added a comment -

            Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/6713/
            Subject: LU-3397 lprocfs: create "export" /proc file on server
            Project: fs/lustre-release
            Branch: master
            Current Patch Set:
            Commit: b4b773466a0f3a178364e62b8549de08a3f9ce32

            gerrit Gerrit Updater added a comment - Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/6713/ Subject: LU-3397 lprocfs: create "export" /proc file on server Project: fs/lustre-release Branch: master Current Patch Set: Commit: b4b773466a0f3a178364e62b8549de08a3f9ce32
            adilger Andreas Dilger added a comment -

            Trying to revive this patch again for 2.9.

            What about having a single obdfilter/*/exports/$NID/export file, but in the case there are multiple exports for the same NID (e.g. client connecting to multiple OSTs on one node} then there would be multiple entries in the export file? Since it is YAML formatted, it would be possible to prefix the data output with device: $obd_name or similar to disambiguate them. This would avoid overhead from having to open/parse/close multiple export files, and also avoid the naming issue for those files.

            The other option is to have files like .../export-$obd_name and each one has only the data for that device. The complexity I see here is that there would be a bunch of these files (1-8 typically), that would likely always be read together, and accessing them needs a priori knowledge of what the device names will be, and they will be different for every server.

            adilger Andreas Dilger added a comment - Trying to revive this patch again for 2.9. What about having a single obdfilter/*/exports/$NID/export file, but in the case there are multiple exports for the same NID (e.g. client connecting to multiple OSTs on one node} then there would be multiple entries in the export file? Since it is YAML formatted, it would be possible to prefix the data output with device: $obd_name or similar to disambiguate them. This would avoid overhead from having to open/parse/close multiple export files, and also avoid the naming issue for those files. The other option is to have files like .../export-$obd_name and each one has only the data for that device. The complexity I see here is that there would be a bunch of these files (1-8 typically), that would likely always be read together, and accessing them needs a priori knowledge of what the device names will be, and they will be different for every server.
            emoly.liu Emoly Liu added a comment -

            James, Yangsheng ever had a similar idea in http://review.whamcloud.com/#/c/9857/, but Andreas thought it would break all tools that are using the per-NID statistics, and also, the only time there were multiple mounts on the same NID would be during testing.

            I don't mind discussing it again.

            emoly.liu Emoly Liu added a comment - James, Yangsheng ever had a similar idea in http://review.whamcloud.com/#/c/9857/ , but Andreas thought it would break all tools that are using the per-NID statistics, and also, the only time there were multiple mounts on the same NID would be during testing. I don't mind discussing it again.
            simmonsja James A Simmons added a comment - - edited

            I have been working with the patch in question and have found a issue with the location of where to place the data. It is not true that
            obdfilter/*/exports/$NID/export is a per client directory. For example if you build all of lustre on one node and cat obdfilter/*/exports/$NID/uuid you get

            62fde21f-fbc4-cced-7862-e1ccb9cdea09
            lustre-MDT0000-mdtlov_UUID

            So it is multiple values. For your export to do the similar behavior it would have multiple entries. Do we really want that? I think a better approach would be to create directory entries such as obdfilter/*/exports/"obd-device"/export instead.

            simmonsja James A Simmons added a comment - - edited I have been working with the patch in question and have found a issue with the location of where to place the data. It is not true that obdfilter/*/exports/$NID/export is a per client directory. For example if you build all of lustre on one node and cat obdfilter/*/exports/$NID/uuid you get 62fde21f-fbc4-cced-7862-e1ccb9cdea09 lustre-MDT0000-mdtlov_UUID So it is multiple values. For your export to do the similar behavior it would have multiple entries. Do we really want that? I think a better approach would be to create directory entries such as obdfilter/*/exports/"obd-device"/export instead.
            simmonsja James A Simmons added a comment -

            We can mark this a 2.7 project.

            simmonsja James A Simmons added a comment - We can mark this a 2.7 project.
            adilger Andreas Dilger added a comment -

            http://review.whamcloud.com/6713

            adilger Andreas Dilger added a comment - http://review.whamcloud.com/6713

            People

              emoly.liu Emoly Liu
              adilger Andreas Dilger
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: