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-14412 Lustre <p>Trying to change client side max_read_ahead_whole_mb setting returns error. </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> r633i6n8 ~ # lctl get_param llite.nbp12-ffff95b4806d1800.max_read_ahead_mb llite.nbp12-ffff95b4806d1800.max_read_ahead_mb=4096 r633i6n8 ~ # lctl set_param llite.nbp12-ffff95b4806d1800.max_read_ahead_whole_mb=512 error: set_param: setting /sys/kernel/debug/lustre/llite/nbp12-ffff95b4806d1800/max_read_ahead_whole_mb=512: Numerical result out of range? </pre> </div></div> <p> </p> LU-14412

changing max_read_ahead_whole_mb results in error "Numerical result out of range? "

Bug Major Resolved Fixed Yang Sheng Mahmoud Hanafi Wed, 10 Feb 2021 18:54:16 +0000 Thu, 18 Mar 2021 21:19:24 +0000 Thu, 18 Mar 2021 21:19:24 +0000 Lustre 2.12.5 0 5 <p>It looks like this parameter can't be larger than <tt>llite.*.max_read_ahead_per_file_mb</tt>. It should have printed a message on the console like:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>nbp12: can't set max_read_ahead_whole_mb=512 &gt; max_read_ahead_per_file_mb=256 </pre> </div></div> <p>or similar. </p> <p>One option to make this more usable, would be rather than returning an error in this case to increase <tt>max_read_ahead_per_file_mb</tt> to match the specified <tt>max_read_ahead_whole_mb</tt> value if it is not large enough.</p> <p>You can't set max_read_ahead_whole_mb to be larger than max_read_ahead_per_file_mb. That is why you see this error.</p> <p>Got it thanks.</p> <p> </p> <p>On a side note, I would be interested to understand what your motivation is for setting <tt>max_read_ahead_whole_mb=512</tt>? IMHO, this is <em>probably</em> not desirable as a general tuning, unless you have a random read workload that accesses the whole file, but the file is small enough to fit into cache (e.g. like <a href="https://jira.whamcloud.com/browse/LU-11416" title="Improve readahead for random read of small/medium files" class="issue-link" data-issue-key="LU-11416">LU-11416</a>)? Or is your workload always accessing large files and the overhead of detecting sequential access is worse than fetching files up to 512MB to the client is negligible?</p> <p>We have a very specific work load that opens lots of small files (&lt;100MB) and will do small read (4KB or less). The job memory foot print is small so the client has lots of memory for cache. We are experimenting with these setting hoping to increase their read performance.  </p> <p>we can close this</p> Development Rank 1|i01m9r: Rank (Obsolete) 9223372036854775807 Severity