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-16669 Lustre <p>Lustre advise IOCTL interface can set the CEF_LOCK_NO_EXPAND flag, which tells the OSC (the per OST layer of the client) to set LDLM_FL_NO_EXPANSION on any lock requests. LDLM_FL_NO_EXPANSION is a new LDLM lock flag which tells the server not to expand the lock extent.</p> <p>To set this parameter much easier for benchmark or debug purpose, It would better to add a tunable "llite.*.lock_no_expand" to control whether to expand the lock extent for I/O.</p> LU-16669

Add lock_no_expand tunable on the Lustre client

Improvement Minor Open Unresolved Qian Yingjin Qian Yingjin Mon, 27 Mar 2023 07:48:41 +0000 Tue, 4 Jul 2023 09:43:04 +0000 0 3 <p>"Qian Yingjin &lt;qian@ddn.com&gt;" uploaded a new patch: <a href="https://review.whamcloud.com/c/fs/lustre-release/+/50432" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/c/fs/lustre-release/+/50432</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-16669" title="Add lock_no_expand tunable on the Lustre client" class="issue-link" data-issue-key="LU-16669">LU-16669</a> llite: add lock_no_expand tunable on a client<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: b5cb732703272e4919e9e3c7af2bb8b88498e287</p> <p>Yingjin, could you please provide some background on what this is needed for? I don't see it linked to any other tickets, and there isn't enough explanation in the description to know what this would be used for.</p> <p>I'm wondering if we should add a new <tt>LF_INODE</tt> flag so that "<tt>lfs ladvise locknoexpand &lt;file&gt;</tt>" could be set persistently on an inode rather than just a file descriptor? Would that be more useful for applications or test scripts instead of adding a <tt>CFS_FAIL_CHECK()</tt> that affects all files on the node?</p> <p>Hi Andreas,</p> <p>There are two motivations for this work:</p> <ul class="alternate" type="square"> <li>It is mainly used for benchmark purpose;</li> <li>Strided writes from many clients with page aligned. It does expand the I/O locking extent to reduce the lock ping-pong callbacks. (compared with strided writes using direct I/O).</li> </ul> <p>Of course we can add a new LF_INODE flag to be set persistently on an inode for "lfs ladies locknoexpand $file".</p> <p>But I am just worried about its narrow usage scope...</p> <p>I think in the second case, it makes sense for the client or OSS to detect the lock contention and avoid lock expansion. This already happens on the OSS today with 32+ clients writing to a single file, but it does not take into account disjoint writes with fewer clients. </p> <p>I just rebased Patrick's lock contention detection patch: <a href="https://review.whamcloud.com/#/c/fs/lustre-release/+/35287/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/fs/lustre-release/+/35287/</a>.<br/> We can use this patch to detect the lock contention on the OSS, and clients will be informed when the OST object is under lock contention.</p> <p>Both client and server can determine to whether avoid lock expansion under lock contention.</p> <p>Moreover, when the client was informed that the file is under contention, it can switch from default buffered I/O mode to direct I/O mode if the I/O size is large enough.</p> Related LU-16939 Development Rank 1|i03h8v: Rank (Obsolete) 9223372036854775807