[LU-1081] LUSTRE_BFL_FID has a conflicting namespace

• Type: Bug
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.2.0, Lustre 2.3.0
• Affects Version/s: Lustre 2.2.0
• Story Points: 2
• Assignee: Di Wang
• Reporter: Andreas Dilger

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.

Issue Links

• Trackbacks: Changelog 2.2 version 2.2.0 Support for networks: o2iblnd OFED 1.5.4 Server support for kernels: 2.6.32220.4.2.el6 (RHEL6) Client support for unpatched kernels: 2.6.18274.18.1.el5 (RHEL5) 2.6.32220.4.2.el6 (RHEL6) 2.6.32.360....