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

nodemap: wildcard '*@<net>' is broken

Details

    • Bug
    • Resolution: Fixed
    • Minor
    • Lustre 2.12.0, Lustre 2.10.4
    • Lustre 2.9.0
    • None
    • CentOS 7.2, Lustre-2.8.60
    • 3
    • 9223372036854775807

    Description

      Hi, this is a minor bug report for nodemap. The nodemap documentation indicates that wildchar is allowed:

      <nidrange>      :== <addrrange> '@' <net>
      <addrrange>     :== '*' |
                              <ipaddr_range> |
                              <numaddr_range>
      
      
      
      
      

      but it doesn't seem to work as expected, as it just adds a single IP 0.0.0.0:

      $ cat /proc/fs/lustre/nodemap/sherlock/ranges
      [
      
      ]
      $ lctl nodemap_add_range --name sherlock --range '*@o2ib3'
      $ cat /proc/fs/lustre/nodemap/sherlock/ranges
      [
       { id: 18, start_nid: 0.0.0.0@o2ib3, end_nid: 0.0.0.0@o2ib3 }
      ]
      
      
      
      
      

      As a workaround, we can use [0-255].[0-255].[0-255].[0-255]@o2ib3, in that case the full range of IP is added:

      [
       { id: 19, start_nid: 0.0.0.0@o2ib3, end_nid: 255.255.255.255@o2ib3 }
      ]
      
      
      

      Note: Four wildchars separated by dots also work but I don't believe it should according to the documentation.

      Thanks,
      Stephan

      Attachments

        Activity

          [LU-8913] nodemap: wildcard '*@<net>' is broken

          John L. Hammond (john.hammond@intel.com) merged in patch https://review.whamcloud.com/31950/
          Subject: LU-8913 nodemap: fix nodemap range format '*@<net>' support
          Project: fs/lustre-release
          Branch: b2_10
          Current Patch Set:
          Commit: 9721fa40d09b0686a568c8a3ad78bf6502f5acb2

          gerrit Gerrit Updater added a comment - John L. Hammond (john.hammond@intel.com) merged in patch https://review.whamcloud.com/31950/ Subject: LU-8913 nodemap: fix nodemap range format '*@<net>' support Project: fs/lustre-release Branch: b2_10 Current Patch Set: Commit: 9721fa40d09b0686a568c8a3ad78bf6502f5acb2

          Minh Diep (minh.diep@intel.com) uploaded a new patch: https://review.whamcloud.com/31950
          Subject: LU-8913 nodemap: fix nodemap range format '*@<net>' support
          Project: fs/lustre-release
          Branch: b2_10
          Current Patch Set: 1
          Commit: 404de6606a31f8569ffe2ee701469d690cd260a3

          gerrit Gerrit Updater added a comment - Minh Diep (minh.diep@intel.com) uploaded a new patch: https://review.whamcloud.com/31950 Subject: LU-8913 nodemap: fix nodemap range format '*@<net>' support Project: fs/lustre-release Branch: b2_10 Current Patch Set: 1 Commit: 404de6606a31f8569ffe2ee701469d690cd260a3

          Thanks!

          sthiell Stephane Thiell added a comment - Thanks!
          pjones Peter Jones added a comment -

          Landed for 2.12

          pjones Peter Jones added a comment - Landed for 2.12

          Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/31684/
          Subject: LU-8913 nodemap: fix nodemap range format '*@<net>' support
          Project: fs/lustre-release
          Branch: master
          Current Patch Set:
          Commit: 230266326f49b0e6aab43c1d1a5c926d78c11e53

          gerrit Gerrit Updater added a comment - Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/31684/ Subject: LU-8913 nodemap: fix nodemap range format '*@<net>' support Project: fs/lustre-release Branch: master Current Patch Set: Commit: 230266326f49b0e6aab43c1d1a5c926d78c11e53

          Emoly Liu (emoly.liu@intel.com) uploaded a new patch: https://review.whamcloud.com/31684
          Subject: LU-8913 nodemap: fix nodemap range format '*@<net>' support
          Project: fs/lustre-release
          Branch: master
          Current Patch Set: 1
          Commit: 6ddf2aa90cb8a39a9469007c65f55e1b9d362038

          gerrit Gerrit Updater added a comment - Emoly Liu (emoly.liu@intel.com) uploaded a new patch: https://review.whamcloud.com/31684 Subject: LU-8913 nodemap: fix nodemap range format '*@<net>' support Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: 6ddf2aa90cb8a39a9469007c65f55e1b9d362038
          emoly.liu Emoly Liu added a comment -

          OK, thanks for your information. I will fix it.

          emoly.liu Emoly Liu added a comment - OK, thanks for your information. I will fix it.

          As a side note, such `*@net` wildcard patterns can be used elsewhere in Lustre, for example:

          mgs# lctl conf_param testfs.mdt.nosquash_nids="*@tcp"
          

          from https://build.hpdd.intel.com/job/lustre-manual/lastSuccessfulBuild/artifact/lustre_manual.xhtml#dbdoclet.50438221_48757

          sthiell Stephane Thiell added a comment - As a side note, such `*@net` wildcard patterns can be used elsewhere in Lustre, for example: mgs# lctl conf_param testfs.mdt.nosquash_nids="*@tcp" from https://build.hpdd.intel.com/job/lustre-manual/lastSuccessfulBuild/artifact/lustre_manual.xhtml#dbdoclet.50438221_48757

          Hi Emoly,

          Fine but the documentation states that a single wildcard is supported so it probably needs to be updated unless I'm reading this wrong. Example at https://build.hpdd.intel.com/job/lustre-manual/lastSuccessfulBuild/artifact/lustre_manual.xhtml#idm139929611418592:

          <nidrange>      :== <addrrange> '@' <net>
          <addrrange>     :== '*' |
                                  <ipaddr_range> |
                                  <numaddr_range>
          

          the devil is in the details

          Thanks for looking at this.
          Stephane

          sthiell Stephane Thiell added a comment - Hi Emoly, Fine but the documentation states that a single wildcard is supported so it probably needs to be updated unless I'm reading this wrong. Example at https://build.hpdd.intel.com/job/lustre-manual/lastSuccessfulBuild/artifact/lustre_manual.xhtml#idm139929611418592 : <nidrange> :== <addrrange> '@' <net> <addrrange> :== '*' | <ipaddr_range> | <numaddr_range> the devil is in the details Thanks for looking at this. Stephane
          emoly.liu Emoly Liu added a comment - - edited

          Hi sthiell,
          IMO, '*' means full range [0-255], so usually we use '*.*.*.*@o2ib3' but not '*@o2ib3'. I just had a test, both '*.*.*.*@o2ib3' and '[0-255].[0-255].[0-255].[0-255]@o2ib3' work correctly as follows,

          # lctl nodemap_add_range --name nm1 --range '*.*.*.*@o2ib3'
          # lctl get_param nodemap.nm1.ranges
          nodemap.nm1.ranges=
          [
           { id: 5, start_nid: 0.0.0.0@o2ib3, end_nid: 255.255.255.255@o2ib3 }
          ]
          # lctl nodemap_del_range --name nm1 --range '*.*.*.*@o2ib3'
          # lctl nodemap_add_range --name nm1 --range '[0-255].[0-255].[0-255].[0-255]@o2ib3'
          # lctl get_param nodemap.nm1.ranges
          nodemap.nm1.ranges=
          [
           { id: 6, start_nid: 0.0.0.0@o2ib3, end_nid: 255.255.255.255@o2ib3 }
          ]
          

          Thanks,
          Emoly

          emoly.liu Emoly Liu added a comment - - edited Hi sthiell , IMO, '*' means full range [0-255] , so usually we use '*.*.*.*@o2ib3' but not '*@o2ib3'. I just had a test, both '*.*.*.*@o2ib3' and ' [0-255] . [0-255] . [0-255] . [0-255] @o2ib3' work correctly as follows, # lctl nodemap_add_range --name nm1 --range '*.*.*.*@o2ib3' # lctl get_param nodemap.nm1.ranges nodemap.nm1.ranges= [ { id: 5, start_nid: 0.0.0.0@o2ib3, end_nid: 255.255.255.255@o2ib3 } ] # lctl nodemap_del_range --name nm1 --range '*.*.*.*@o2ib3' # lctl nodemap_add_range --name nm1 --range '[0-255].[0-255].[0-255].[0-255]@o2ib3' # lctl get_param nodemap.nm1.ranges nodemap.nm1.ranges= [ { id: 6, start_nid: 0.0.0.0@o2ib3, end_nid: 255.255.255.255@o2ib3 } ] Thanks, Emoly

          People

            emoly.liu Emoly Liu
            sthiell Stephane Thiell
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: