https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-2684 Lustre <p>After <a href="https://jira.whamcloud.com/browse/LU-2682" title="clean up direct _id and _seq access, use ost_id everywhere" class="issue-link" data-issue-key="LU-2682"><del>LU-2682</del></a> 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.</p> <p>This will unify MDT and OST object identification, as well as DLM locking.</p> LU-2684

convert ost_id to lu_fid for FID_SEQ_NORMAL objects

Technical task LU-1185 Blocker Resolved Fixed Di Wang Andreas Dilger LB Fri, 25 Jan 2013 18:52:31 +0000 Tue, 7 May 2013 21:12:51 +0000 Fri, 12 Apr 2013 23:23:20 +0000 Lustre 2.4.0 Lustre 2.4.0 0 5 <p>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.</p> <p><a href="http://review.whamcloud.com/5820" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5820</a></p> <p>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.</p> <p>Andreas: <br/> If we change this object id identification to be an union<br/> </p> { struct ost_id oid; struct lu_fid fid; } <p>;</p> <p>struct ost_id {<br/> __u64 oi_id;<br/> __u64 oi_seq;<br/> }</p> <p>struct lu_fid {<br/> __u64 f_seq;<br/> __u32 f_oid;<br/> __u32 f_ver;<br/> }</p> <p>So when id comes in, we can check whether the object id by this</p> <p> if (fid_seq_is_mdt0(oi-&gt;o_seq) || fid_seq_is_echo(oi-&gt;o_seq) || fid_seq_is_llog(oi-&gt;o_seq)) {</p> <p> }</p> <p>But there are some questions</p> <p>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?</p> <p>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?</p> <p>Could you please give some suggestion here?</p> <p>Di, could you please post the email I sent you to this bug. I don't have access to it right now.</p> <p>Here are replies from Andreas</p> <p>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?</p> <p>Andreas:<br/> "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."</p> <p>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?</p> <p>Andreas:<br/> No, we never use ver today, it should not conflict until we support fid on OST everywhere. </p> <p>Landed for 2.4</p> <p>this is what I got with gcc-4.7.2:</p> <p>In file included from /work/lustre/head1/lustre/ofd/ofd_obd.c:45:0:<br/> /work/lustre/head1/lustre/ofd/ofd_obd.c: In function 'ofd_punch':<br/> /work/lustre/head1/lustre/include/lustre/lustre_idl.h:582:3: error: 'oi.&lt;Ud390&gt;.oi.oi_id' may be used uninitialized in this function <span class="error">&#91;-Werror=uninitialized&#93;</span><br/> In file included from /work/lustre/head1/lustre/ofd/ofd_internal.h:43:0,<br/> from /work/lustre/head1/lustre/ofd/ofd_obd.c:46:<br/> /work/lustre/head1/lustre/include/lustre_fid.h:626:17: note: 'oi.&lt;Ud390&gt;.oi.oi_id' was declared here<br/> In file included from /work/lustre/head1/lustre/ofd/ofd_obd.c:45:0:<br/> /work/lustre/head1/lustre/ofd/ofd_obd.c: In function 'ofd_destroy_by_fid':<br/> /work/lustre/head1/lustre/include/lustre/lustre_idl.h:582:3: error: 'oi.&lt;Ud390&gt;.oi.oi_id' may be used uninitialized in this function <span class="error">&#91;-Werror=uninitialized&#93;</span><br/> In file included from /work/lustre/head1/lustre/ofd/ofd_internal.h:43:0,<br/> from /work/lustre/head1/lustre/ofd/ofd_obd.c:46:<br/> /work/lustre/head1/lustre/include/lustre_fid.h:626:17: note: 'oi.&lt;Ud390&gt;.oi.oi_id' was declared here<br/> In file included from /work/lustre/head1/lustre/ofd/ofd_obd.c:45:0:<br/> /work/lustre/head1/lustre/ofd/ofd_obd.c: In function 'ofd_setattr':<br/> /work/lustre/head1/lustre/include/lustre/lustre_idl.h:582:3: error: 'oi.&lt;Ud390&gt;.oi.oi_id' may be used uninitialized in this function <span class="error">&#91;-Werror=uninitialized&#93;</span><br/> In file included from /work/lustre/head1/lustre/ofd/ofd_internal.h:43:0,<br/> from /work/lustre/head1/lustre/ofd/ofd_obd.c:46:<br/> /work/lustre/head1/lustre/include/lustre_fid.h:626:17: note: 'oi.&lt;Ud390&gt;.oi.oi_id' was declared here<br/> cc1: all warnings being treated as errors</p> <p>seem to be related ?</p> <p>Sigh, I am still using gcc-4.4.6 here. But I post a patch here <a href="http://review.whamcloud.com/6016" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6016</a>, Could you please check whether this will help? Thanks</p> <p>reopen for tracking compiling warning alex mentioned.</p> <p>Closing again - the compiler issue is being handled along with the fix for <a href="https://jira.whamcloud.com/browse/LU-2888" title="After downgrade from 2.4 to 2.1.4, hit (osd_handler.c:2343:osd_index_try()) ASSERTION( dt_object_exists(dt) ) failed" class="issue-link" data-issue-key="LU-2888"><del>LU-2888</del></a></p> Duplicate LU-1139 Related LU-3179 LU-2682 LU-3187 LU-2888 Development Rank 1|hzvg73: Rank (Obsolete) 6271