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-7334 Lustre <p>The lprocfs helper functions for parsing __u64 and ints from strings are currently a bit messy. These should be re-written to leverage a single set of internal functions. This change will replace these helpers with a small set of new helpers that will return an __s64. Any functions calling the old helpers will be changed to accommodate their replacement.</p> LU-7334

Refactor lprocfs helpers

Improvement Minor Resolved Fixed Emoly Liu Giuseppe Di Natale llnl patch Fri, 23 Oct 2015 18:42:36 +0000 Tue, 6 Jun 2017 21:05:05 +0000 Sat, 9 Jul 2016 14:13:33 +0000 Lustre 2.9.0 0 8 <p>I will be submitting a patch for testing this shortly. No need for code reviews yet.</p> <p>Giuseppe Di Natale (dinatale2@llnl.gov) uploaded a new patch: <a href="http://review.whamcloud.com/16930" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/16930</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7334" title="Refactor lprocfs helpers" class="issue-link" data-issue-key="LU-7334"><del>LU-7334</del></a> lprocfs: Refactored string to value helpers<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: fb65e6b0b6ec11cc2521e32396fa1ccd4855d434</p> <p>Emoly</p> <p>Could you please review and look after this patch?</p> <p>Thanks</p> <p>Peter</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/16930/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/16930/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7334" title="Refactor lprocfs helpers" class="issue-link" data-issue-key="LU-7334"><del>LU-7334</del></a> lprocfs: Refactored string to value helpers<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 1cd2189806c82c31256c5ef9756d1dbf97784844</p> <p>Landed for 2.9.0.</p> <p>We've noticed some regressions with this patch, in particular <a href="https://jira.whamcloud.com/browse/LU-8139" title="sanity test_101g: &#39;max_pages_per_rpc not correctly set&#39;" class="issue-link" data-issue-key="LU-8139">LU-8139</a> was causing sanity failures because both this <a href="http://review.whamcloud.com/16930" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/16930</a> patch and <a href="http://review.whamcloud.com/19368" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/19368</a> were tested and passed independently, but caused failures when both were landed.</p> <p>It seems that several /proc files that previously were using <tt>lprocfs_write_u64_helper()</tt> and accepted a unit suffix have been changed to <tt>lprocfs_str_to_s64()</tt> and no longer accept units. These include:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>lod_stripesize_seq_write() lod_stripeoffset_seq_write() lov_stripesize_seq_write()* lov_stripeoffset_seq_write()* osc_cur_grant_bytes_seq_write() osc_obd_max_pages_per_rpc_seq_write()+ ldiskfs_osd_readcache_seq_write() </pre> </div></div> <p><span class="error">&#91;*&#93;</span> The "lov_stripesize_seq_&#42;()" tunables are non-functional since 2.4.0 and should just be deleted, they were replaced by the "lod_&#42;" equivalents.<br/> <span class="error">&#91;+&#93;</span> Oleg has already submitted a patch to fix osc_obd_max_pages_per_rpc_seq_write() (<a href="http://review.whamcloud.com/20243" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/20243</a>) since this was causing sanity.sh to fail.</p> <p>The others are just potential sources of failures that should be fixed to avoid problems with end-user configurations that are setting these parameters.</p> <p>Does this imply that we need a version of the function which doesn't accept a default unit, but will allow for units to be present in the string? The reason I ask is because Oleg's change appears to be a work around to have a default multiplier of 1, unless of course there is a unit in the string. I really don't like the idea of passing in '%' as the work around to accomplish a default multiplier of 1.</p> <p>The other option is to have a new unit 'B'/'b' for bytes with a multiplier of 1, but that can clash with the hex value B. Also, if we allow the new unit, we could disallow units to be part of hex strings? It seems unlikely that a hex value would represent a quantity, but I could be wrong.</p> <p>Also, "b" is used in some cases to mean "blocks", which would be confusing. Since the default unit is passed as a separate string, using "1" for the units would work and also be clear?</p> <p>I also found the following failure:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># echo 1000 &gt; /proc/fs/lustre/mdt/lustre-MDT0000/hsm/max_requests -bash: echo: write error: Invalid argument </pre> </div></div> <p>No weird values involved. That worked fine up to that patch.</p> <p>That's because my processing function doesn't allow a newline before the null terminator. I will fix that too.</p> <p>Giuseppe Di Natale (dinatale2@llnl.gov) uploaded a new patch: <a href="http://review.whamcloud.com/20353" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/20353</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7334" title="Refactor lprocfs helpers" class="issue-link" data-issue-key="LU-7334"><del>LU-7334</del></a> lprocfs: Allow a new line before null terminator<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 9f3e8fca14009bf0372a470f333a68e7e6e4c9b9</p> <p>I'm not sure a "1" unit is the way to go either. Since using 'B/b' is appearing to be some what confusing, I'm leaning towards a version of lprocfs_str_with_units_to_s64 that has no default unit, meaning it is expecting just a number (multiplier is 1 by default) and will parse a unit if it encounters one. But even that I'm not 100% happy with.</p> <p>I like using '1' for the units better than creating a new function.</p> <p>Andreas, when you say remove the "lov_stripesize_seq_*()" tunables, you mean removing the proc file as a whole, correct?</p> <p>Correct. These /proc tunables were replaced on the MDS with "lod_stripesize_seq_<b>()" and the "lov_</b>" code is now only used on the client, where these tunables are totally useless.</p> <p>Giuseppe Di Natale (dinatale2@llnl.gov) uploaded a new patch: <a href="http://review.whamcloud.com/20455" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/20455</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7334" title="Refactor lprocfs helpers" class="issue-link" data-issue-key="LU-7334"><del>LU-7334</del></a> lprocfs: Few proc files are numbers, but use units.<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: e8bb349c927eced4c927850ce69a981ac38664a1</p> <p>Should I introduce a change to re-enable sanity test 101g?</p> <p>Giuseppe Di Natale (dinatale2@llnl.gov) uploaded a new patch: <a href="http://review.whamcloud.com/20465" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/20465</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7334" title="Refactor lprocfs helpers" class="issue-link" data-issue-key="LU-7334"><del>LU-7334</del></a> lproc: Remove lov_stripesize and lov_stripeoffset<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 2475a20d42b6d423578f35953d260897ac466da5</p> <p>The enabling of test 101g is being done via <a href="http://review.whamcloud.com/20281" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/20281</a></p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/20353/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/20353/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7334" title="Refactor lprocfs helpers" class="issue-link" data-issue-key="LU-7334"><del>LU-7334</del></a> lprocfs: Allow a new line before null terminator<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: db44a9e35a9c115d69bca82014ceec4c5fc336dd</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/20465/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/20465/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7334" title="Refactor lprocfs helpers" class="issue-link" data-issue-key="LU-7334"><del>LU-7334</del></a> lov: Cleanup lov_stripe proc files<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: d34b9dfbebc8d313be9c12a96b660a34ad45edcb</p> <p>Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: <a href="http://review.whamcloud.com/21129" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/21129</a><br/> Subject: Revert "<a href="https://jira.whamcloud.com/browse/LU-7334" title="Refactor lprocfs helpers" class="issue-link" data-issue-key="LU-7334"><del>LU-7334</del></a> lov: Cleanup lov_stripe proc files"<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: dd2bbdb66a2f5a43b63dd5a42f1702a652af9ffd</p> <p>Just noticed <a href="http://review.whamcloud.com/20465/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/20465/</a> caused some issues. Should that change be abandoned?</p> <p>I thought setting the default lov with proc was a bad idea? Patch 20465 seems to not break anything but just adds a bogus error at client mount time.Is this not true?</p> <p>It was reverted. From the description in <a href="https://jira.whamcloud.com/browse/LU-8338" title="lov.*-clilov-*.stripe* params not consistent with FS defaults" class="issue-link" data-issue-key="LU-8338">LU-8338</a>, the error at mount time might be harmless.</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/20455/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/20455/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7334" title="Refactor lprocfs helpers" class="issue-link" data-issue-key="LU-7334"><del>LU-7334</del></a> lprocfs: Allow default multiplier of 1<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 2fc4838533668135d2efe98b90e56a9ac5dadaea</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/21129/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/21129/</a><br/> Subject: Revert "<a href="https://jira.whamcloud.com/browse/LU-7334" title="Refactor lprocfs helpers" class="issue-link" data-issue-key="LU-7334"><del>LU-7334</del></a> lov: Cleanup lov_stripe proc files"<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 4af430de697249d07bcb7fe3401a6caa4415fe31</p> <p>It looks like all patches have landed for 2.9 now</p> Related LU-8139 LU-8338 LU-9611 LU-9091 Development End date Thu, 26 May 2016 18:42:36 +0000 Rank 1|hzxr9r: Rank (Obsolete) 9223372036854775807 Start date Fri, 23 Oct 2015 18:42:36 +0000