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-11554 Lustre <p>Currently, stat() does not work with LSOM yet, so using "ls -l" or "mdtest" for testing is not a going to exercise the LSOM code.<br/> We should add mount options or proc interface (<em>lctl set_param llite.*.lsom=1</em>) to enable using LSOM as retruned file's size and blocks for stat() system call, and make stat() behavior selectable.</p> LU-11554

Make stat() work with LSOM

Improvement Minor Resolved Duplicate Qian Yingjin Qian Yingjin LSOM Mon, 22 Oct 2018 06:52:04 +0000 Thu, 11 Jun 2020 08:36:34 +0000 Thu, 11 Jun 2020 08:36:34 +0000 0 5 <p>Yingjin Qian (qian@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/33412" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/33412</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11554" title="Make stat() work with LSOM" class="issue-link" data-issue-key="LU-11554"><del>LU-11554</del></a> som: Make stat() work with LSOM<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 3eb06b38ac88e42b12de4afd81c98c202d879076</p> <p>I think this is a lot like <a href="https://jira.whamcloud.com/browse/LU-10934" title="integrate statx() API with Lustre" class="issue-link" data-issue-key="LU-10934"><del>LU-10934</del></a>. The <tt>statx()</tt> API already has a mechanism to allow "lazy" size to be send to userspace applications that know they don't care about the exact size. I don't think it would be practical/possible to have <b>all</b> size on a mountpoint return the LSOM size via regular <tt>stat()</tt>, since that would be much more likely to cause data loss (eg. client not reading all file data because the size is too small).</p> <p>I think the integration of LSOM with "<tt>lfs find</tt>" is much higher priority. Also, FLR and DoM have totally correct SOM size/blocks, so if DoM is used to store the majority of small files, this will also avoid the majority of need for accurate SOM size. </p> <p>I think the only thing we should do here is use known valid SOM data (not "lazy") from the MDS if it is available and can be returned to the client (e.g. from FLR files, or if a scrubbing process verifies the size and updates the state on the MDT inode like <a href="https://jira.whamcloud.com/browse/LU-11962" title="File LSOM updates to store proper size via FLR for regular stat() usage" class="issue-link" data-issue-key="LU-11962">LU-11962</a> from userspace).</p> <p>I think some argument could be made that if a file is accessed for read but it has not been modified in some time (e.g. a day or more), then the overhead of doing an extra RPC to start modifying it is outweighed by the benefit of doing fewer RPCs to the OSTs to get the size. </p> <p>Closing this as a duplicate of <a href="https://jira.whamcloud.com/browse/LU-11962" title="File LSOM updates to store proper size via FLR for regular stat() usage" class="issue-link" data-issue-key="LU-11962">LU-11962</a>, which describes a way to have "LSOM" updates usable for regular <tt>stat()</tt> operations.</p> Related LU-11962 LU-11367 LU-10934 LU-11916 Development Rank 1|i004pz: Rank (Obsolete) 9223372036854775807