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-16064 Lustre <p>when a client gets evicted OST cancels its locks, but don't wait for its RPCs to complete. this way another client can get a conflicting lock and modify data, but then in-progress RPC from the evicted client can modify data as well. then we get a situation when the healty client holding LDLM lock has some data/state in his cache which don't match actual data stored on OST.</p> LU-16064

RPC from evicted client can corrupt data

Bug Minor In Progress Unresolved Alex Zhuravlev Alex Zhuravlev Tue, 2 Aug 2022 09:02:36 +0000 Fri, 1 Dec 2023 11:46:09 +0000 Lustre 2.16.0 0 10 <p>"Alex Zhuravlev &lt;bzzz@whamcloud.com&gt;" uploaded a new patch: <a href="https://review.whamcloud.com/48102" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/48102</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-16064" title="RPC from evicted client can corrupt data" class="issue-link" data-issue-key="LU-16064">LU-16064</a> ldlm: block lock cancellation<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 1c767540c426e6b0bf13772f1a2f73b8f50cc6c2</p> <p>the approach taken in the patch has a prolem - MDS can get stuck if RPC being processed needs to evict own client. not sure how to handle this yet.. thinking.</p> <p>Alex, </p> <p>If I right understand - this problem should be solved in different way and fix will be much simple.<br/> BRW code should pickup an extra ldlm lock reference when IO processed.<br/> So this lock can't be granted until brw code will release own reference - so no data consistence problem.</p> <p>what you think about it?</p> Related LU-16224 LU-16345 Development Rank 1|i02vzb: Rank (Obsolete) 9223372036854775807 Severity