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-12550 Lustre <p>This is something Li Xi suggested a few years ago - It should be possible to do lockahead automatically by tracking the write pattern (like <a href="https://jira.whamcloud.com/browse/LU-12468" title="Add writeahead state tracking" class="issue-link" data-issue-key="LU-12468">LU-12468</a>) and using server-side contention checking to tell the client when to do this.  (Lockahead is currently only usable by clients which know to ask for it.)</p> <p>This should let clients get good performance when strided writes with non-stripe aligned i/o, as long as the i/o is page aligned (LDLM &amp; OSC locks are at page granularity).</p> LU-12550

automatic lockahead

Improvement Minor Open Unresolved Patrick Farrell Patrick Farrell Mon, 15 Jul 2019 20:17:50 +0000 Fri, 1 Sep 2023 00:53:58 +0000 0 6 <p>This is just a side project right now, but I have a quick prototype, and wanted to get it in git.</p> <p><del>Patrick Farrell (pfarrell@whamcloud.com) uploaded a new patch:</del> <a href="https://review.whamcloud.com/35526" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35526</a><br/> <del>Subject: <a href="https://jira.whamcloud.com/browse/LU-12550" title="automatic lockahead" class="issue-link" data-issue-key="LU-12550">LU-12550</a> llite: Automatic lockahead</del><br/> <del>Project: fs/lustre-release</del><br/> <del>Branch: master</del><br/> <del>Current Patch Set: 1</del><br/> <del>Commit: b87252145170765ad40dfd390d7497f366eae171</del></p> <p>Instead of doing lockahead for small unaligned writes, I think it is probably better to just do lockless "direct" writes to the OST. That avoids the overhead of the <tt>LDLM_ENQUEUE</tt> RPC to lockahead the lock, when we <em>still</em> need to do the write from the client.</p> <p>Even if the lockahead was expanded to cover whole pages (risking some lock contention on the hopes that sparse random writers will have few conflicts), unaligned writes would have to do read-modify-write of the partial pages. That means at least 3 RPCs (<tt>LDLM_ENQUEUE</tt> for lockahead, <tt>OST_READ</tt> of the start/end page(s), and the <tt>OST_WRITE</tt>), but up to 6 (if separate <tt>OST_READ</tt> RPCs are sent for the start/end pages, <tt>LDLM_BL_CALLBACK</tt> if there is a conflict for the expanded lock region, and <tt>LDLM_CANCEL</tt> if the lock can't be cancelled with ELC on the <tt>OST_WRITE</tt>).</p> <p>Conversely, lockless writes would only be one <tt>OST_WRITE</tt> RPC, and may even avoid the RDMA round-trip if it is a short write that fits into the RPC request (though that is not different than the <tt>OST_WRITE</tt> for the locked write).</p> <p>As Andreas said above, the scope for automatic lockahead is pretty limited and I have no intention of reviving this work.</p> <p>However, the contention detection patch here:<br/> <a href="https://review.whamcloud.com/#/c/35287/6" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/35287/6</a></p> <p>Can be extracted from the writeahead tracking &amp; automatic lockahead patches and used for switching from buffered i/o (which cannot be lockless) to direct i/o (which can be lockless).</p> Related LU-13802 LU-13805 LU-12426 LU-12468 LU-16939 LU-16964 Development Rank 1|i00jon: Rank (Obsolete) 9223372036854775807