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-3491 Lustre <p>The printing of i_ino/i_generation in llite messages is not nearly so useful as printing the full inode FID, since i_ino is a "compressed" version of the FID and there may be duplicate values for i_ino in some cases (especially if running on a 32-bit client).</p> <p>An audit should be made of i_ino/i_generation usage in the lustre/</p> {llite,mdc} <p>/*.c files, and replace this with DFID/PFID(ll_inode2fid(inode)).</p> LU-3491

replace printing of i_ino in llite with ll_inode2fid()

Improvement Minor Resolved Fixed James Nunez Andreas Dilger Fri, 21 Jun 2013 00:58:10 +0000 Fri, 5 Jun 2015 00:32:23 +0000 Sat, 2 Nov 2013 03:06:53 +0000 Lustre 2.5.0 Lustre 2.6.0 0 3 <p>The patch, for llite, for this ticket is almost complete, but a couple of questions came to mind while modifying the code. </p> <p>1. Do we want consistency in the way the inode/FID is printed? Sometimes we print the FID first then the inode in parenthesis. Other times we print the inode first and then the FID in parenthesis. Examples:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">CDEBUG(D_DLMTRACE, <span class="code-quote">"setting l_ast_data to inode %p ("</span>DFID<span class="code-quote">")\n"</span>, inode, PFID(ll_inode2fid(inode))); </pre> </div></div> <p>and</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">CDEBUG(D_VFSTRACE, <span class="code-quote">"VFS Op:name=%.*s,dir="</span>DFID<span class="code-quote">"(%p),intent=%s\n"</span>, dentry-&gt;d_name.len, dentry-&gt;d_name.name, PFID(ll_inode2fid(dir)), dir, LL_IT2STR(it)); </pre> </div></div> <p>2. Whenever possible, do we want to print the inode along with the FID? For example, we have times where we just print the Fid:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">CERROR(<span class="code-quote">"inode "</span>DFID<span class="code-quote">": rc = %d\n"</span>, PFID(ll_inode2fid(inode)), rc); </pre> </div></div> <p>Should we actually print, when possible:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">CERROR(<span class="code-quote">"inode %p ("</span>DFID<span class="code-quote">"): rc = %d\n"</span>, inode, PFID(ll_inode2fid(inode)), rc); </pre> </div></div> <p>3. In some files, I see the following:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">CDEBUG(D_INFO, <span class="code-quote">"encoding <span class="code-keyword">for</span> (%lu,"</span>DFID<span class="code-quote">") maxlen=%d minlen=%d\n"</span>, inode-&gt;i_ino, PFID(ll_inode2fid(inode)), *plen, (<span class="code-object">int</span>)sizeof(struct lustre_nfs_fid)); </pre> </div></div> <p>and </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">CDEBUG(D_INFO, <span class="code-quote">"getting parent <span class="code-keyword">for</span> (%lu,"</span>DFID<span class="code-quote">")\n"</span>, dir-&gt;i_ino, PFID(ll_inode2fid(dir))); </pre> </div></div> <p>It seems redundant to print both i_ino and FID for the same inode. Should we just print the FID in these cases?</p> <p>James, thanks for your attention to the details.</p> <p>I agree that printing both the FID and i_ino is redundant, since the inode number is just a compressed 32-bit or 64-bit version of the FID.</p> <p>Please always print the device name or fsname at the start of any console error message. If we need to print the inode pointer, it should be in parenthesis after the FID, since it is much less important that the FID, and will rarely be of use to anyone without a crashdump. </p> <p>Proposed patch for llite is at:</p> <p><a href="http://review.whamcloud.com/6848" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6848</a></p> <p>Accidentally closed issue. Patch has not landed yet.</p> <p>Landed to master</p> Development Rank 1|hzvtqn: Rank (Obsolete) 8775