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

LUSTRE_BFL_FID has a conflicting namespace

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: Lustre 2.2.0
    • Fix Version/s: Lustre 2.2.0, Lustre 2.3.0
    • Labels:
      None
    • Story Points:
      2
    • Rank (Obsolete):
      4685

      Description

      The LUSTRE_BFL_FID is being used as a global filesystem rename lock, but the FID sequence is not using a well-defined FID_SEQ_* value. The current value "3" is in conflict with the FID_SEQ_OST_MDT1 range, but it should more properly be controlled by MDT0.

      Is this value currently (2.1/2.2) used outside of MDT0? If not, then it should be trivial to change before DNE is released. Otherwise, this needs to be handled in some manner that does not cause problems in the future.

      /* Lustre Big Fs Lock fid. */
      const struct lu_fid LUSTRE_BFL_FID = { .f_seq = 0x0000000000000003,
                                             .f_oid = 0x0000000000000001,
                                             .f_ver = 0x0000000000000000 };
      EXPORT_SYMBOL(LUSTRE_BFL_FID);
      
      static int mdt_rename_lock(struct mdt_thread_info *info,
                                 struct lustre_handle *lh)
      {
              ms = mdt_md_site(info->mti_mdt);
              fid_build_reg_res_name(&LUSTRE_BFL_FID, res_id);
      

      Part of the problem is that these FID constants are being declared in a "local" header lustre_fid.h, rather than a global public header like "lustre_idl.h". I don't mind having a separate "public" lustre_fid.h header, as long as it is installed into /usr/include/lustre/lustre_fid.h so that it is accessible to external programs. That would allow moving all of the FID-related constants out to this header, such as FID_SEQ_* enum, the fid_seq_*() helper functions (which are useful in some user tools like lfsck), etc.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                di.wang Di Wang
                Reporter:
                adilger Andreas Dilger
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: