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-11291 Lustre <p>We has some files that were created with 2.11 client and 2.10.3 server that hit <a href="https://jira.whamcloud.com/browse/LU-10437" title="sanity-pfl test_8: dbench failed" class="issue-link" data-issue-key="LU-10437"><del>LU-10437</del></a> bug. We have since update our server to 2.10.5. But the old files still can't bee seen by the user. We get this.</p> <p>on 2.11 clients + updated 2.10.5 server</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> $ ls -l ls: cannot access <span class="code-quote">'test'</span>: Invalid argument total 1040384 -????????? ? ? ? ? ? test </pre> </div></div> <p>on 2.10.3 clients + updated 2.10.5 server</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> ls -l test -rw------- yyyy xxx 8388608 Aug 28 15:44 test </pre> </div></div> <p>Only root can view them correctly.<br/> Can we recover those files with-out copying them. </p> LU-11291

recovering from LU-10437

Bug Major Resolved Cannot Reproduce Jian Yu Mahmoud Hanafi Tue, 28 Aug 2018 23:06:03 +0000 Wed, 5 Oct 2022 23:28:46 +0000 Wed, 5 Oct 2022 23:28:46 +0000 Lustre 2.11.0 Lustre 2.10.3 0 5 <p>here is what we get in the logs.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> [588862.457231] LustreError: 96988:0:(lcommon_cl.c:187:cl_file_inode_init()) Failure to initialize cl object [0x200000bd6:0xc7d1:0x0]: -22 [588862.457245] LustreError: 96988:0:(llite_lib.c:2357:ll_prep_inode()) new_inode -fatal: rc -22 </pre> </div></div> <p>If the problem relates to FLR functionality added in 2.11 as indicated in <a href="https://jira.whamcloud.com/browse/LU-10437" title="sanity-pfl test_8: dbench failed" class="issue-link" data-issue-key="LU-10437"><del>LU-10437</del></a>, it is possible that running a layout LFSCK on the MDT would detect and correct this problem. However, the FLR support for LFSCK was only recently landed (commit v2_11_53_0-33-g36ba989 patch <a href="https://review.whamcloud.com/32705" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/32705</a> "<tt><a href="https://jira.whamcloud.com/browse/LU-10288" title="LFSCK support for mirrored files" class="issue-link" data-issue-key="LU-10288"><del>LU-10288</del></a> lfsck: layout LFSCK for mirrored file</tt>") so that functionality is not available in the MDS version you are using, nor in any released version to date.</p> <p>My recommendation would be to find the inaccessible files with a 2.11 client, and then use "<tt>lfs migrate</tt>" on a 2.10 client to fix the layout. Depending on what "<tt>lfs getstripe -v</tt>" reports for such files (e.g. strange <tt>lcme_flags</tt>) it may be possible to use something like "<tt>lfs find /mnt/lustre --comp-count +1 --comp-flags=stale,prefer,offline</tt>" to find these files on a 2.10 client directly. Depending on how many files the <tt>lfs find</tt> operation locates, it may well be faster to migrate them to clear the flags rather than waiting for a code fix to be developed, tested, and be installed on your system.</p> <p>Jian,<br/> for future usage, it would be desirable for "<tt>lfs getstripe</tt>" to also print out unknown flags in hex form after it has printed all of the known flags, like "<tt>init,prefer,0x18c40</tt>" so that we have some forward compatibility when new flags are added. Similarly, "<tt>lfs find</tt>" should be able to search for flags by hex value in addition to named flags for the same reason. That would allow something like "<tt>lfs find --comp-flags 0x7fffffe0 ...</tt>" to locate any files with flags that we don't currently have assigned. It <em>might</em> be desirable to allow a modified master "<tt>lfs --component-set</tt>" to clear some the offending flags directly from the client without doing the migration, but that is not possible for all of the flags (e.g. <tt>stale</tt> at least). We might consider to allow clearing the <tt>stale</tt> flag from a component if all of the <tt>init</tt>'d components in the file are stale.</p> <p>Sure, Andreas, I'll work on these improvements.</p> Related LU-9463 LU-10437 Development Rank 1|i001dr: Rank (Obsolete) 9223372036854775807 Severity