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

LU-12514 (lustre_tgt mount type) breaks scripts that used 'mount -t lustre' and expected targets

Details

    • Bug
    • Resolution: Fixed
    • Major
    • Lustre 2.14.0
    • Lustre 2.13.0
    • None
    • 3
    • 9223372036854775807

    Description

      LU-12514 (utils: add "lustre_tgt" filesystem type) breaks scripts that used 'mount -t lustre' and expected to see targets.

      In 2.12.*:

      # mount -t lustre
      /dev/mapper/mds1_flakey on /mnt/lustre-mds1 type lustre (ro,svname=lustre-MDT0000,mgs,osd=osd-ldiskfs,user_xattr,errors=remount-ro)
      /dev/mapper/ost1_flakey on /mnt/lustre-ost1 type lustre (ro,svname=lustre-OST0000,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro)
      /dev/mapper/ost2_flakey on /mnt/lustre-ost2 type lustre (ro,svname=lustre-OST0001,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro)
      /dev/mapper/ost3_flakey on /mnt/lustre-ost3 type lustre (ro,svname=lustre-OST0002,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro)
      /dev/mapper/ost4_flakey on /mnt/lustre-ost4 type lustre (ro,svname=lustre-OST0003,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro)
      192.168.122.75@tcp:/lustre on /mnt/lustre type lustre (rw,flock,user_xattr,lazystatfs)
      # mount -t lustre_tgt
      # 
      

      In 2.13 and on:

      # mount -t lustre
      192.168.122.75@tcp:/lustre on /mnt/lustre type lustre (rw,flock,user_xattr,lazystatfs,noencrypt)
      # mount -t lustre_tgt
      /dev/mapper/ost1_flakey on /mnt/lustre-ost1 type lustre_tgt (ro,svname=lustre-OST0000,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro)
      /dev/mapper/ost2_flakey on /mnt/lustre-ost2 type lustre_tgt (ro,svname=lustre-OST0001,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro)
      /dev/mapper/ost3_flakey on /mnt/lustre-ost3 type lustre_tgt (ro,svname=lustre-OST0002,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro)
      /dev/mapper/ost4_flakey on /mnt/lustre-ost4 type lustre_tgt (ro,svname=lustre-OST0003,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro)
      /dev/mapper/mds1_flakey on /mnt/lustre-mds1 type lustre_tgt (ro,svname=lustre-MDT0000,mgs,osd=osd-ldiskfs,user_xattr,errors=remount-ro)
      

      Attachments

        Issue Links

          Activity

            [LU-14061] LU-12514 (lustre_tgt mount type) breaks scripts that used 'mount -t lustre' and expected targets
            pjones Peter Jones added a comment -

            Landed for 2.14

            pjones Peter Jones added a comment - Landed for 2.14

            Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/40474/
            Subject: LU-14061 utils: prefer mounting with specified fstype
            Project: fs/lustre-release
            Branch: master
            Current Patch Set:
            Commit: ffeb900743772d86ceb41b4a323006fd478fd674

            gerrit Gerrit Updater added a comment - Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/40474/ Subject: LU-14061 utils: prefer mounting with specified fstype Project: fs/lustre-release Branch: master Current Patch Set: Commit: ffeb900743772d86ceb41b4a323006fd478fd674

            Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/40474
            Subject: LU-14061 utils: prefer mounting with specified fstype
            Project: fs/lustre-release
            Branch: master
            Current Patch Set: 1
            Commit: a79f8111eb6ad27d42a4a04cc9f20e74bdbcbc8c

            gerrit Gerrit Updater added a comment - Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/40474 Subject: LU-14061 utils: prefer mounting with specified fstype Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: a79f8111eb6ad27d42a4a04cc9f20e74bdbcbc8c

            So this appears to be a bug in mount_lustre.c that it is always using "lustre_tgt" for server targets instead of what was requested:

                    if (!mop.mo_fake) {
                            char *fstype = client ? "lustre" : "lustre_tgt";
            
                            /*
                             * flags and target get to lustre_get_sb(), but not
                             * lustre_fill_super().  Lustre ignores the flags, but mount
                             * does not.
                             */
                            for (i = 0, rc = -EAGAIN; i <= mop.mo_retry && rc != 0; i++) {
                                    rc = mount(mop.mo_source, mop.mo_target, fstype,
                                               flags, (void *)options);
                                    if (rc != 0) {
                                            /* Older Lustre without 'lustre_tgt'.
                                             * Try 'lustre' instead
                                             */
                                            if (rc == -ENODEV) {
                                                    fstype = "lustre";
                                                    i--;
                                                    continue;
                                            }
            

            This should check basename(argv[0]) to see if it is called as "mount.lustre" and preferably use "lustre" in that case, and "mount.lustre_tgt" should preferably use "lustre_tgt" then. For server mountpoints it could also try "lustre_tgt" if the first mount fails with -ENODEV.

                    if (!mop.mo_fake) {
                            char *fstype = "lustre";
            
                            if (strstr(argv[0], "mount.lustre_tgt"))
                                    fstype = "lustre_tgt";
            
                            /*
                             * flags and target get to lustre_get_sb(), but not
                             * lustre_fill_super().  Lustre ignores the flags, but mount
                             * does not.
                             */
                            for (i = 0, rc = -EAGAIN; i <= mop.mo_retry && rc != 0; i++) {
                                    rc = mount(mop.mo_source, mop.mo_target, fstype,
                                               flags, (void *)options);
                                    if (rc != 0) {
                                            /* Older Lustre without 'lustre_tgt'.
                                             * Try 'lustre' instead
                                             */
                                            if (rc == -ENODEV && strcmp(fstype, "lustre_tgt")) {
                                                    fstype = "lustre";
                                                    i--;
                                                    continue;
                                            }
            
            adilger Andreas Dilger added a comment - So this appears to be a bug in mount_lustre.c that it is always using " lustre_tgt " for server targets instead of what was requested: if (!mop.mo_fake) { char *fstype = client ? "lustre" : "lustre_tgt" ; /* * flags and target get to lustre_get_sb(), but not * lustre_fill_super(). Lustre ignores the flags, but mount * does not. */ for (i = 0, rc = -EAGAIN; i <= mop.mo_retry && rc != 0; i++) { rc = mount(mop.mo_source, mop.mo_target, fstype, flags, (void *)options); if (rc != 0) { /* Older Lustre without 'lustre_tgt' . * Try 'lustre' instead */ if (rc == -ENODEV) { fstype = "lustre" ; i--; continue ; } This should check basename(argv [0] ) to see if it is called as " mount.lustre " and preferably use " lustre " in that case, and " mount.lustre_tgt " should preferably use " lustre_tgt " then. For server mountpoints it could also try " lustre_tgt " if the first mount fails with -ENODEV . if (!mop.mo_fake) { char *fstype = "lustre" ; if (strstr(argv[0], "mount.lustre_tgt" )) fstype = "lustre_tgt" ; /* * flags and target get to lustre_get_sb(), but not * lustre_fill_super(). Lustre ignores the flags, but mount * does not. */ for (i = 0, rc = -EAGAIN; i <= mop.mo_retry && rc != 0; i++) { rc = mount(mop.mo_source, mop.mo_target, fstype, flags, (void *)options); if (rc != 0) { /* Older Lustre without 'lustre_tgt' . * Try 'lustre' instead */ if (rc == -ENODEV && strcmp(fstype, "lustre_tgt" )) { fstype = "lustre" ; i--; continue ; }
            jhammond John Hammond added a comment -

            > how were the server filesystems mounted originally? Did they get mounted with "mount -t lustre" or "mount -t lustre_tgt" initially?

            Using mount -t lustre.

            k:~# mount -t lustre
            192.168.122.75@tcp:/lustre on /mnt/lustre type lustre (rw,flock,user_xattr,lazystatfs,noencrypt)
            k:~# mount -t lustre_tgt
            ...
            /dev/mapper/ost1_flakey on /mnt/lustre-ost1 type lustre_tgt (ro,svname=lustre-OST0000,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro)
            k:~# umount /mnt/lustre-ost1/
            k:~# mount /dev/mapper/ost1_flakey /mnt/lustre-ost1 -t lustre
            k:~# mount -t lustre
            192.168.122.75@tcp:/lustre on /mnt/lustre type lustre (rw,flock,user_xattr,lazystatfs,noencrypt)
            k:~# mount -t lustre_tgt
            ...
            /dev/mapper/ost1_flakey on /mnt/lustre-ost1 type lustre_tgt (ro,svname=lustre-OST0000,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro)
            
            jhammond John Hammond added a comment - > how were the server filesystems mounted originally? Did they get mounted with "mount -t lustre" or "mount -t lustre_tgt" initially? Using mount -t lustre . k:~# mount -t lustre 192.168.122.75@tcp:/lustre on /mnt/lustre type lustre (rw,flock,user_xattr,lazystatfs,noencrypt) k:~# mount -t lustre_tgt ... /dev/mapper/ost1_flakey on /mnt/lustre-ost1 type lustre_tgt (ro,svname=lustre-OST0000,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro) k:~# umount /mnt/lustre-ost1/ k:~# mount /dev/mapper/ost1_flakey /mnt/lustre-ost1 -t lustre k:~# mount -t lustre 192.168.122.75@tcp:/lustre on /mnt/lustre type lustre (rw,flock,user_xattr,lazystatfs,noencrypt) k:~# mount -t lustre_tgt ... /dev/mapper/ost1_flakey on /mnt/lustre-ost1 type lustre_tgt (ro,svname=lustre-OST0000,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro)
            adilger Andreas Dilger added a comment - - edited

            John, how were the server filesystems mounted originally? Did they get mounted with "mount -t lustre" or "mount -t lustre_tgt" initially? Since 2.13, "mount -t lustre" will internally call "mount.lustre" and "mount -t lustre_tgt" will internally call "mount.lustre_tgt", but both are the same binary and will try "lustre_tgt" first for server mountpoints (block devices) and then fall back to using "lustre" if that doesn't work. I tested a trivial change to "mount_lustre.c" that only uses "lustre", and "mount -t lustre" now works fine. It would probably be trivial to distinguish via "argv[0]" which binary is being called and use that preferentially so that the mounted type matches what is requested.

            Since commit v2_12_58-71-g510aea4a37, the use of lustre_tgt is optional so it is still possible to mount a server as type lustre to give some time to migrate system configurations. We definitely want to keep this compatibility until at least the next LTS, so that there is at least one commonly-used release where it is possible to use either type so upgrade/downgrade is possible without a flag day for changing the configuration at the same time. Possibly for 2.14 or 2.15 it seems reasonable to add a message to mount.lustre and/or the kernel to warn if lustre is used for a server mountpoint, but that wouldn't cause any errors for users.

            John also pointed out that "stat -f" should handle this as well. This will currently report "UNKNOWN (0xbd00bd1)" as the filesystem magic (LUSTRE_SUPER_MAGIC), regardless of what type it was mounted as. This is also true on my 2.10.8 server, so it is not a regression introduced by LU-12514. It makes sense to submit an upstream patch to fix this to return "lustre_tgt" so that it is correct by the time it makes its way into the vendor distros. If anyone is using bleeding-edge coreutils it is likely that they are also using a newer Lustre release, or this is on the client where it doesn't matter since it returns magic "LL_SUPER_MAGIC = 0x0bd00bd0" which is mapped to "lustre" in userspace.

            adilger Andreas Dilger added a comment - - edited John, how were the server filesystems mounted originally? Did they get mounted with " mount -t lustre " or " mount -t lustre_tgt " initially? Since 2.13, " mount -t lustre " will internally call " mount.lustre " and " mount -t lustre_tgt " will internally call " mount.lustre_tgt ", but both are the same binary and will try " lustre_tgt " first for server mountpoints (block devices) and then fall back to using " lustre " if that doesn't work. I tested a trivial change to " mount_lustre.c " that only uses " lustre ", and "mount -t lustre" now works fine. It would probably be trivial to distinguish via " argv [0] " which binary is being called and use that preferentially so that the mounted type matches what is requested. Since commit v2_12_58-71-g510aea4a37 , the use of lustre_tgt is optional so it is still possible to mount a server as type lustre to give some time to migrate system configurations. We definitely want to keep this compatibility until at least the next LTS , so that there is at least one commonly-used release where it is possible to use either type so upgrade/downgrade is possible without a flag day for changing the configuration at the same time. Possibly for 2.14 or 2.15 it seems reasonable to add a message to mount.lustre and/or the kernel to warn if lustre is used for a server mountpoint, but that wouldn't cause any errors for users. John also pointed out that " stat -f " should handle this as well. This will currently report " UNKNOWN (0xbd00bd1) " as the filesystem magic ( LUSTRE_SUPER_MAGIC ), regardless of what type it was mounted as. This is also true on my 2.10.8 server, so it is not a regression introduced by LU-12514 . It makes sense to submit an upstream patch to fix this to return " lustre_tgt " so that it is correct by the time it makes its way into the vendor distros. If anyone is using bleeding-edge coreutils it is likely that they are also using a newer Lustre release, or this is on the client where it doesn't matter since it returns magic " LL_SUPER_MAGIC = 0x0bd00bd0 " which is mapped to " lustre " in userspace.

            This is not a solution for existing scripts.

            jhammond John Hammond added a comment - This is not a solution for existing scripts.

            The solution is to update to 'mount -t lustre,lustre_tgt'. NFS did the same thing for NFSv4 support.  The idea of a 'lustre' file system type for both servers and clients works well since the normal setup is separate nodes for clients and servers. If mounting a light weight client will be the norm in the future on server nodes I can see a 'lustre' for all leading to problems.

            simmonsja James A Simmons added a comment - The solution is to update to 'mount -t lustre,lustre_tgt'. NFS did the same thing for NFSv4 support.  The idea of a 'lustre' file system type for both servers and clients works well since the normal setup is separate nodes for clients and servers. If mounting a light weight client will be the norm in the future on server nodes I can see a 'lustre' for all leading to problems.

            People

              adilger Andreas Dilger
              jhammond John Hammond
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: