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-14111 Lustre <p>Eviction is a standard mechanism for Lustre targets to protect themselves against dead or misbehaving clients.</p> <p>On a live filesystem, evictions happen, eventually and it could be useful for sysadmin to have an exact counter to monitor them and take action if needed.</p> <p>I will propose a patch where an eviction counter is added to obd_device, increased when an eviction occurs and exposed through lctl get_param.</p> LU-14111

Report per-target eviction count

Improvement Minor Resolved Fixed Aurelien Degremont Aurelien Degremont Tue, 3 Nov 2020 15:47:05 +0000 Sat, 3 Feb 2024 05:19:07 +0000 Tue, 14 Feb 2023 13:27:23 +0000 Lustre 2.16.0 0 5 <p>Aurelien Degremont (degremoa@amazon.com) uploaded a new patch: <a href="https://review.whamcloud.com/40528" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/40528</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-14111" title="Report per-target eviction count" class="issue-link" data-issue-key="LU-14111"><del>LU-14111</del></a> obdclass: count eviction per obd_device<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: ecfa119aafe911e5ee8949d5b082fd4dc742e35f</p> <p>Actually, this information is already in <tt>osc.*.import</tt>:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> connection: failover_nids: [ 192.168.20.1@tcp ] current_connection: 192.168.20.1@tcp connection_attempts: 2623 generation: 2623 in-progress_invalidations: 0 idle: 0 sec </pre> </div></div> <p>so it makes sense to include this information there. </p> <p>But the patch is tracking that server-side, not client side.</p> <p> </p> <p>I was wondering where was a good place to report that data on server-side and as I understood that the move away from /proc is pushing a direction where new data should have its own /sys entries, rather than adding it to a more complex output one.</p> <p> </p> <p>(moving this out of the patch review as this is not related)</p> <blockquote><p>The upstream kernel folks are just starting to come to this realization, and trying to do crazy things like adding a syscall to read from an array of fd's at the same time, but it is just more efficient to have all of the values in a single file that is formatted for easy parsing (YAML).</p></blockquote> <p>I was thinking for a while that lots of get_param entries has a yaml-like syntax or almost yaml-compatible and that this was a good path forward, but I've never seen any commitment or official recommendation that's the way to go and that those params should be made YAML compatible as mush as possible?</p> <p> </p> <p>I don't know if there was ever an "official" documentation to that effect, but at WC the use of YAML has definitely been adopted as the standard format for <b>new</b> "complex" parameter files ever since IML started to be developed.</p> <p>From my experience, it is possible to create YAML-compliant files (I use <a href="http://yaml-online-parser.appspot.com/" class="external-link" target="_blank" rel="nofollow noopener">http://yaml-online-parser.appspot.com/</a> to verify this) that are both machine readable and human readable. Examples of "new" complex files include <tt>osc.&#42;.import</tt> and <tt>obdfilter.&#42;.exports.&#42;.export</tt>, <tt>obdfilter.&#42;.job_stats</tt>, <tt>obdfilter.&#42;.lfsck_status</tt>, and others. Also, there is a "<tt>lfs getstripe --yaml</tt>" option for dumping file layouts in YAML format, and "<tt>lctl --device MGS llog_print $fsname-client</tt>" and "<tt>lctl --device MGS llog_print params</tt>" to dump the config records.</p> <p>Ideally, we could also convert old "complex" files (e.g. <tt>brw_stats</tt>, but with a new filename) over to YAML format as well, but that hasn't happened yet.</p> <p>"Oleg Drokin &lt;green@whamcloud.com&gt;" merged in patch <a href="https://review.whamcloud.com/c/fs/lustre-release/+/40528/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/c/fs/lustre-release/+/40528/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-14111" title="Report per-target eviction count" class="issue-link" data-issue-key="LU-14111"><del>LU-14111</del></a> obdclass: count eviction per obd_device<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 3c69d46e1766480c0ffd1bef840b4e167b4cf88e</p> <p>Landed for 2.16</p> <p>New maloo test fails in interop with 2.15</p> <p>I see a discussion of YAML output for various parameters. I'm working on a YAML netlink version for the debugfs issue. It should provide the ability to express any stats in YAMl format when requested.</p> <p>"James Simmons &lt;jsimmons@infradead.org&gt;" uploaded a new patch: <a href="https://review.whamcloud.com/c/fs/lustre-release/+/52098" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/c/fs/lustre-release/+/52098</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-14111" title="Report per-target eviction count" class="issue-link" data-issue-key="LU-14111"><del>LU-14111</del></a> tests: only support recovery-small test 146 for 2.15.54+<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 77f9f3232f685b10518596ac69f2961ba7c342fa</p> <p>"Oleg Drokin &lt;green@whamcloud.com&gt;" merged in patch <a href="https://review.whamcloud.com/c/fs/lustre-release/+/52098/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/c/fs/lustre-release/+/52098/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-14111" title="Report per-target eviction count" class="issue-link" data-issue-key="LU-14111"><del>LU-14111</del></a> tests: only support recovery-small test 146 for 2.15.54+<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: b034dd27dd39483e40f91ea82d3f5c62b514ec54</p> Related Development Rank 1|i01e5b: Rank (Obsolete) 9223372036854775807