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

LBUG reading /proc/fs/lustre/mgs/MGS/fstype

Details

    • Story
    • Resolution: Fixed
    • Minor
    • Lustre 2.4.0
    • Lustre 2.4.0
    • CentOS 6.3
    • 5613

    Description

      An MGS has a NULL obd_fsops.

      cat /proc/fs/lustre/mgs/MGS/fstype
      
      LustreError: 4219:0:(lprocfs_status.c:604:lprocfs_rd_fstype()) ASSERTION( obd->obd_fsops != ((void *)0) ) failed: 
      LustreError: 4219:0:(lprocfs_status.c:604:lprocfs_rd_fstype()) LBUG
      

      Attachments

        Activity

          [LU-2358] LBUG reading /proc/fs/lustre/mgs/MGS/fstype
          pjones Peter Jones added a comment -

          Landed for 2.4

          pjones Peter Jones added a comment - Landed for 2.4

          An issue for the sanity check has been created; see LU-2376.

          jhammond John Hammond added a comment - An issue for the sanity check has been created; see LU-2376 .
          emoly.liu Emoly Liu added a comment -

          Should we add a sanity.sh test to check all the readable lustre proc entries to avoid such error?

          emoly.liu Emoly Liu added a comment - Should we add a sanity.sh test to check all the readable lustre proc entries to avoid such error?

          I worry that we will have many links in lustre procfs tree making that difficult to understand where each entry belongs to. I am just not sure how e2fsck uses that, but if all data is placed already in OSD procfs directory, maybe we need to check it there? For example, proposed patch makes two things - link proper OSD proc entry to the particular MGS and then link fstype and mntdev right from there to the MGS too. I wonder just if we have already proper OSD link, can't we check those fields there?

          tappro Mikhail Pershin added a comment - I worry that we will have many links in lustre procfs tree making that difficult to understand where each entry belongs to. I am just not sure how e2fsck uses that, but if all data is placed already in OSD procfs directory, maybe we need to check it there? For example, proposed patch makes two things - link proper OSD proc entry to the particular MGS and then link fstype and mntdev right from there to the MGS too. I wonder just if we have already proper OSD link, can't we check those fields there?

          Mike, if they symlink to the proper OSD device, then it should be ok? One reason for these files is that the mnt dev is used by e2fsck to detect that the device is mounted by Lustre. It is also useful for the admin on occasions to see this.

          adilger Andreas Dilger added a comment - Mike, if they symlink to the proper OSD device, then it should be ok? One reason for these files is that the mnt dev is used by e2fsck to detect that the device is mounted by Lustre. It is also useful for the admin on occasions to see this.
          emoly.liu Emoly Liu added a comment -

          Andreas, do you have any idea about these entries?

          emoly.liu Emoly Liu added a comment - Andreas, do you have any idea about these entries?

          Sorry, I had wrong impression just after reading comments in patch. I see now that it will link properly. But I wonder still do we really need these entries?

          tappro Mikhail Pershin added a comment - Sorry, I had wrong impression just after reading comments in patch. I see now that it will link properly. But I wonder still do we really need these entries?

          I am afraid this will not work if MGS is set up separately from MDT and/or if it is based on osd-zfs. Can we just remove fstype and mntdev entries from MGS/ completely?

          tappro Mikhail Pershin added a comment - I am afraid this will not work if MGS is set up separately from MDT and/or if it is based on osd-zfs. Can we just remove fstype and mntdev entries from MGS/ completely?
          emoly.liu Emoly Liu added a comment -

          I will review this patch.

          emoly.liu Emoly Liu added a comment - I will review this patch.
          jhammond John Hammond added a comment - Please see http://review.whamcloud.com/#change,4635 .

          People

            emoly.liu Emoly Liu
            jhammond John Hammond
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: