[#LU-1081] LUSTRE_BFL_FID has a conflicting namespace

[LU-1081] LUSTRE_BFL_FID has a conflicting namespace Created: 08/Feb/12 Updated: 27/Sep/12 Resolved: 05/Apr/12
Status:	Resolved
Project:	Lustre
Component/s:	None
Affects Version/s:	Lustre 2.2.0
Fix Version/s:	Lustre 2.2.0, Lustre 2.3.0

Type:

Bug

Priority:

Major

Reporter:

Andreas Dilger

Assignee:

Di Wang

Resolution:

Fixed

Votes:

Labels:

None

Story Points:

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.

Comments

Comment by Andreas Dilger [ 21/Feb/12 ]

Di can you please comment on whether this constant is used over the network, or only internal to the MDS?

Comment by Di Wang [ 21/Feb/12 ]

Andreas, sorry for late response for this bug. It is only internal to the MDS for current single MDT. Btw: since we will have FID on OST for DNE, it seems the seq between FID_SEQ_OST_MDT1 and FID_SEQ_RSVD should be reserved for other purpose?

Comment by Andreas Dilger [ 22/Feb/12 ]

Di, this LUSTRE_BFL_FID FID should be changed before it is made externally visible for DNE.

I agree it should be possible to reassign FID_SEQ_OST_MDT1.. but I don't think there is an urgent need to do so, unless you think it is better to keep LUSTRE_BFL_FID as-is? In any case, this FID definition needs to move into lustre_idl.h where all of the other well-known SEQ/FID values are declared.

Comment by Di Wang [ 22/Feb/12 ]

Di, this LUSTRE_BFL_FID FID should be changed before it is made externally visible for DNE.

Sure, I just created a patch, http://review.whamcloud.com/2180 Please have a look.