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-15837 Lustre <p>Per Rick's LUG presentation, there are still a number of optimizations for "<tt>lfs find -printf</tt>" that were not included in the original patch <a href="https://review.whamcloud.com/45136" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/45136</a> "<tt><a href="https://jira.whamcloud.com/browse/LU-10378" title="&quot;lfs find&quot; is missing &quot;-printf&quot; support" class="issue-link" data-issue-key="LU-10378"><del>LU-10378</del></a> utils: add formatted printf to lfs find</tt>" landing that should still be addressed:</p> <ul class="alternate" type="square"> <li>selective fetching of metadata attributes. In particular, fetching the projid for a file requires an extra syscall that is unnecessary if the projid is not being printed, at least until <a href="https://jira.whamcloud.com/browse/LU-12480" title="add STATX_PROJID to upstream kernel" class="issue-link" data-issue-key="LU-12480">LU-12480</a> is implemented. Most of the other MDT attributes are "free" once <b>any</b> attribute is read for a file, so it probably doesn't make sense to micro-optimize here.</li> <li>pre-parsing of the <tt>-printf</tt> argument string (assuming this actually shows up in the CPU profile, I'm not sure if it is actually important vs. stat/RPC overhead)</li> <li>maybe others, I didn't catch all of them</li> </ul> LU-15837

"lfs find -printf" improvements

Improvement Major Open Unresolved WC Triage Andreas Dilger easy lad23dd lug23dd Tue, 10 May 2022 20:23:31 +0000 Mon, 23 Oct 2023 15:28:12 +0000 Lustre 2.15.0 Lustre 2.16.0 0 5 <p>It looks like a few additional <tt>-printf</tt> options should be implemented, but nothing overly complex. These would be useful by themselves, and also to implement "<tt>lfs find -ls</tt>":</p> <ul class="alternate" type="square"> <li>"<tt>%i</tt>" - inode number</li> <li>"<tt>%LF</tt>" - Lustre FID</li> <li>"<tt>%k</tt>" - file blocks in kilobytes (should be trivial, just "<tt>%b</tt>/2")</li> <li>"<tt>%M</tt>" - symbolic file access mode (decode file type (<tt>-bcdls+/-rwxSt</tt> UGO permission bits)</li> <li><del>"<tt>%n</tt>" - link count</del> (<a href="https://jira.whamcloud.com/browse/LU-7495" title="lfs find is missing &quot;-links&quot; support" class="issue-link" data-issue-key="LU-7495"><del>LU-7495</del></a>)</li> <li>"<tt>%u</tt>" - username (could be mapped to "<tt>%U</tt>" initially to print numeric UID, and implemented separately)</li> <li>"<tt>%g</tt>" - groupname (use "<tt>%g</tt>" initially, as with "<tt>%u</tt>")</li> </ul> <p>Looking at the strace output for regular file processing it seems like it is doing far too much for most files:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># strace -ttt -T lfs find /mnt/testfs/dir : : 1683657120.708615 getdents(4, /* 102 entries */, 32768) = 6448 &lt;0.000784&gt; 1683657120.709513 ioctl(4, _IOC(_IOC_READ|_IOC_WRITE, 0x69, 0x16, 0x140), 0xea2040) = 0 &lt;0.002730&gt; 1683657120.712309 open("/mnt/testfs/dir/filename_is_long-15", O_RDONLY) = 3 &lt;0.003517&gt; 1683657120.715904 ioctl(3, _IOC(_IOC_READ, 0x66, 0xaf, 0x4), 0x7ffc0a9b3ba0) = 0 &lt;0.000140&gt; 1683657120.716106 ioctl(3, FS_IOC_FSGETXATTR, 0x7ffc0a9b37d0) = 0 &lt;0.000044&gt; 1683657120.716243 newfstatat(4, "filename_is_long-15", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0 &lt;0.000683&gt; 1683657120.717022 write(1, "/mnt/testfs/dir/filename_is_long-15", 36) = 36 &lt;0.000296&gt; /mnt/testfs/dir/filename_is_long-15 1683657120.717386 close(3) = 0 &lt;0.002073&gt; </pre> </div></div> <p>The <tt>ioctl(4, _IOC(_IOC_READ|_IOC_WRITE, 0x69, 0x16, 0x140) = IOC_MDC_GETFILEINFO_V2)</tt> is expected for every file, since it gets the file layout and MDT attributes <b>from the parent directory</b> but we definitely <b>should not</b> be doing <tt>open()</tt> and <tt>ioctl(FS_IOC_FSGETXATTR)</tt> (to get projid) and <tt>newfstatat()</tt> (not sure why?) on <b>every</b> file when we are only printing the pathname. That is a <b>lot</b> of overhead (more than double the original <tt>ioctl(IOC_MDC_GETFILEINFO_V2)</tt> call).</p> <p>Running without <tt>-printf "%p"</tt> shows none of that overhead:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>1683657295.265889 getdents(4, /* 102 entries */, 32768) = 6448 &lt;0.000393&gt; 1683657295.266362 write(1, "/mnt/testfs/dir/filename_is_long-15"..., 36) = 36 &lt;0.000009&gt; /mnt/testfs/dir/filename_is_long-15 1683657295.266446 write(1, "/mnt/testfs/dir/filename_is_long-44"..., 36) = 36 &lt;0.000009&gt; /mnt/testfs/dir/filename_is_long-44 </pre> </div></div> <p>I'm thinking that "gather_all" should be changed to be a <tt>STATX_</tt> bitmask to indicate which fields are needed, and then the code could be changed to check the bitmask when the attributes are being fetched:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> #ifndef STATX_PROJID #define STATX_PROJID 0x40000000 <span class="code-comment">/* only used internally */</span> #endif <span class="code-keyword">if</span> (param-&gt;fp_check_projid || gather_printf &amp; STATX_PROJID) </pre> </div></div> <p>The definition of <tt>STAX_PROJID</tt> would only be used internally until the kernel could itself return projid as part of <tt>statx()</tt> (<a href="https://jira.whamcloud.com/browse/LU-12480" title="add STATX_PROJID to upstream kernel" class="issue-link" data-issue-key="LU-12480">LU-12480</a>).</p> Related LU-5170 LU-12480 LU-15504 LU-15743 LU-7495 LU-10378 LU-16798 LU-16560 LU-16808 LU-17219 LU-16760 LU-16798 Development Rank 1|i02pjb: Rank (Obsolete) 9223372036854775807