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-12659 Lustre <p>The log level of LVB initialization (lvbo_init failed) was changed to CDEBUG/DLMTRACE in commit 8739f132 (<a href="https://jira.whamcloud.com/browse/LU-5042" title="Recovery Lock Replay" class="issue-link" data-issue-key="LU-5042"><del>LU-5042</del></a> ldlm: delay filling resource's LVB upon replay), and that change makes users hard to notice the fail until analyzing the debug log or application report it.</p> LU-12659

change log level for "lvbo_init failed" back to CERROR

Improvement Minor Open Unresolved Gu Zheng Gu Zheng Mon, 12 Aug 2019 01:58:38 +0000 Fri, 4 Oct 2019 14:54:37 +0000 Upstream 0 3 <p>Gu Zheng (gzheng@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/35767" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35767</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-12659" title="change log level for &quot;lvbo_init failed&quot; back to CERROR" class="issue-link" data-issue-key="LU-12659">LU-12659</a> ldlm: change log level for "lvbo_init failed" back to CERROR<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 0bba47c0a7289e32e86cbc296b44ad34d04a3c05</p> <p>Discussion on the patch indicates that this is not very easily fixed::</p> <blockquote> <p>&gt;&gt;&gt; Do you mean it's possible that the file may not exist when<br/> &gt;&gt;&gt; this is called? and it's a legitimate condition. Could you<br/> &gt;&gt;&gt; please show me an example for that?<br/> &gt;&gt;&gt;<br/> &gt;&gt; Yes. Imagine a situation of two clients. One does a lookup<br/> &gt;&gt; on a file and another does unlink.<br/> &gt;&gt; Both got their lookups with EA data back and then one sends<br/> &gt;&gt; in the destroy (now handled by mds) and the other one sends<br/> &gt;&gt; in the stat/getattr to OST. If the destroy wins, the getattr will<br/> &gt;&gt; get a false alarm because the object is already gone.<br/> &gt;<br/> &gt; Is there any better way to distinguish there two conditions<br/> &gt; (legitimate race or objects missing)? IMO, from OST side, the<br/> &gt; phenomenons are the same, object is gone.</p> <p>There's no way to distinguish them that I can think of readily.<br/> But the legitimate race is a lot more common I imagine.</p></blockquote> <p>One possibility that comes to mind to distinguish this race condition is if the client sends the MDT parent FID in its RPC (this might need to be added for getattr/glimpse RPCs) then the OSS can verify if the MDT inode still exists or not, like LFSCK does. The <tt>filter_fid</tt> xattr on the object would be gone at this point, so it would not be usable to determine the parent FID. If the MDT parent inode still exists then this is an error, otherwise it is a harmless race. This would need an extra OSS-&gt;MDS GETATTR RPC, which could cause issues if the MDS is offline or busy, but should only happen in the rare case of a missing object.</p> <p>Another alternative would be to keep the DLM resource around for a short time after unlink (eg. a few seconds) to allow detecting the "just deleted" case from the "has not existed for a long time" case. This would need some asynchronous process to clean up the resources after a timeout, and would consume memory, so probably not ideal.</p> Related LU-5702 Development Rank 1|i00l47: Rank (Obsolete) 9223372036854775807