[LU-2684] convert ost_id to lu_fid for FID_SEQ_NORMAL objects

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.4.0
• Fix Version/s: Lustre 2.4.0
• Type: Technical task
• Priority: Blocker
• Reporter: Andreas Dilger
• Assignee: Di Wang
• Resolution: Fixed
• Labels: LB

Description

After LU-2682 is finished, the final step is to convert FID_SEQ_NORMAL object to use struct lu_fid in place of struct ost_id in all of the places it is used today.

This will unify MDT and OST object identification, as well as DLM locking.

Issue Links

• is duplicated by: LU-1139 Put FID into the wire directly by OBD...
• is related to: LU-3179 gcc 4.7.2 produces the errors since L...
• is related to: LU-2682 clean up direct _id and _seq access, ...
• is related to: LU-3187 Interop 2.3.64<->2.3/2.1: sanity test...
• is related to: LU-2888 After downgrade from 2.4 to 2.1.4, hi...

Comments

[Andreas Dilger]

What needs to be done for this change to be included for the 2.4 release? This is the only time we will be able to convert ostid to lu_fid, since we can check for "o_seq != 0" to decide whether it is a FID or an old object/group=0.

[Di Wang]

http://review.whamcloud.com/5820

[Di Wang]

Andreas: this patch is the just the first try, and it only fix the resid order for data object. I will add more changes later.

[Di Wang]

Andreas:
If we change this object id identification to be an union

{ struct ost_id oid; struct lu_fid fid; }

;

struct ost_id {
__u64 oi_id;
__u64 oi_seq;
}

struct lu_fid {
__u64 f_seq;
__u32 f_oid;
__u32 f_ver;
}

So when id comes in, we can check whether the object id by this

if (fid_seq_is_mdt0(oi->o_seq) || fid_seq_is_echo(oi->o_seq) || fid_seq_is_llog(oi->o_seq)) {

}

But there are some questions

1. o_seq = 0 will never obsolete in current implementation, because MDT0 will always start using seq 0, instead of normal seq, even for new refresh FS and DNE. So it means such conversion will always exists, with this regard, do you think we still need this unification here?

2. we need take care seq 1 (llog) and seq 2 (echo) as well, it means the first two bits of f_ver will be occupied as well, but in some big endian machine, seq(1,2) might be in the space of f_oid, which we can not tell it is normal FID or llog/echo seq. am I right?

Could you please give some suggestion here?

[Andreas Dilger]

Di, could you please post the email I sent you to this bug. I don't have access to it right now.

[Di Wang]

Here are replies from Andreas

question1, o_seq = 0 will never obsolete in current implementation, because MDT0 will always start using seq 0, instead of normal seq, even for new refresh FS and DNE. So it means such conversion will always exists, with this regard, do you think we still need this unification here?

Andreas:
"Yes, in the future when the oldest supported clients are 2.4 and/or we backport seq != 0 support to 2.1 then we can start new filesystems to use fid on OST."

question2, we need take care seq 1 (llog) and seq 2 (echo) as well, it means the first two bits of f_ver will be occupied as well, but in some big endian machine, seq(1,2) might be in the space of f_oid, which we can not tell it is normal FID or llog/echo seq. am I right?

Andreas:
No, we never use ver today, it should not conflict until we support fid on OST everywhere.

[Peter Jones]

Landed for 2.4

[Alex Zhuravlev]

this is what I got with gcc-4.7.2:

In file included from /work/lustre/head1/lustre/ofd/ofd_obd.c:45:0:
/work/lustre/head1/lustre/ofd/ofd_obd.c: In function 'ofd_punch':
/work/lustre/head1/lustre/include/lustre/lustre_idl.h:582:3: error: 'oi.<Ud390>.oi.oi_id' may be used uninitialized in this function [-Werror=uninitialized]
In file included from /work/lustre/head1/lustre/ofd/ofd_internal.h:43:0,
from /work/lustre/head1/lustre/ofd/ofd_obd.c:46:
/work/lustre/head1/lustre/include/lustre_fid.h:626:17: note: 'oi.<Ud390>.oi.oi_id' was declared here
In file included from /work/lustre/head1/lustre/ofd/ofd_obd.c:45:0:
/work/lustre/head1/lustre/ofd/ofd_obd.c: In function 'ofd_destroy_by_fid':
/work/lustre/head1/lustre/include/lustre/lustre_idl.h:582:3: error: 'oi.<Ud390>.oi.oi_id' may be used uninitialized in this function [-Werror=uninitialized]
In file included from /work/lustre/head1/lustre/ofd/ofd_internal.h:43:0,
from /work/lustre/head1/lustre/ofd/ofd_obd.c:46:
/work/lustre/head1/lustre/include/lustre_fid.h:626:17: note: 'oi.<Ud390>.oi.oi_id' was declared here
In file included from /work/lustre/head1/lustre/ofd/ofd_obd.c:45:0:
/work/lustre/head1/lustre/ofd/ofd_obd.c: In function 'ofd_setattr':
/work/lustre/head1/lustre/include/lustre/lustre_idl.h:582:3: error: 'oi.<Ud390>.oi.oi_id' may be used uninitialized in this function [-Werror=uninitialized]
In file included from /work/lustre/head1/lustre/ofd/ofd_internal.h:43:0,
from /work/lustre/head1/lustre/ofd/ofd_obd.c:46:
/work/lustre/head1/lustre/include/lustre_fid.h:626:17: note: 'oi.<Ud390>.oi.oi_id' was declared here
cc1: all warnings being treated as errors

seem to be related ?

[Di Wang]

Sigh, I am still using gcc-4.4.6 here. But I post a patch here http://review.whamcloud.com/6016, Could you please check whether this will help? Thanks

[Di Wang]

reopen for tracking compiling warning alex mentioned.

[Peter Jones]

Closing again - the compiler issue is being handled along with the fix for LU-2888