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-13167 Lustre <p>This issue was created by maloo for liuying &lt;emoly.liu@intel.com&gt;</p> <p>This issue relates to the following test suite run: <a href="https://testing.whamcloud.com/test_sets/69b56d06-3c3b-11ea-b0f4-52540065bddc" class="external-link" target="_blank" rel="nofollow noopener">https://testing.whamcloud.com/test_sets/69b56d06-3c3b-11ea-b0f4-52540065bddc</a></p> <p>test_33b failed with the following error:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>onyx-66vm8: == rpc test complete, duration -o sec ================================================================ 07:30:01 (1579591801) onyx-66vm8: onyx-66vm8.onyx.whamcloud.com: executing _wait_recovery_complete *.lustre-OST0001.recovery_status 1475 onyx-66vm8: *.lustre-OST0001.recovery_status status: COMPLETE sanity-flr test_33b: @@@@@@ FAIL: read mirror too slow without ost2, from 1 to 4 </pre> </div></div> <p>VVVVVVV DO NOT REMOVE LINES BELOW, Added by Maloo for auto-association VVVVVVV<br/> sanity-flr test_33b - read mirror too slow without ost2, from 1 to 4</p> LU-13167

sanity-flr test_33b: read mirror too slow without ost2, from 1 to 4

Bug Minor Open Unresolved Jian Yu Maloo Wed, 22 Jan 2020 07:49:26 +0000 Thu, 6 Jul 2023 13:58:26 +0000 Lustre 2.13.0 Lustre 2.12.3 Lustre 2.12.5 Lustre 2.12.6 Lustre 2.12.9 0 4 <p>The failure also occurred on Lustre b2_12 branch:<br/> <a href="https://testing.whamcloud.com/test_sets/d96923d8-4341-11ea-86b2-52540065bddc" class="external-link" target="_blank" rel="nofollow noopener">https://testing.whamcloud.com/test_sets/d96923d8-4341-11ea-86b2-52540065bddc</a></p> <p>+1 <a href="https://testing.whamcloud.com/test_sets/e8b442a3-09c2-45a4-9860-348fc1ea9015" class="external-link" target="_blank" rel="nofollow noopener">https://testing.whamcloud.com/test_sets/e8b442a3-09c2-45a4-9860-348fc1ea9015</a></p> <p>This test fails intermittently, but steadily over time. I suspect like many tests that are measuring performance when running in a VM that there are inconsistencies in the system performance that may be causing this. However, I also don't like to disable the test completely or ignore all errors (with <tt>error_not_in_vm</tt>) because we very rarely run these tests on real hardware, so there would be no way to detect if the test started failing regularly.</p> <p>Ideally, the test framework could monitor the failure rate (e.g. 1/30 failures on a branch) and then consider it a real failure if a patch failed more often than that. It <em>might</em> be possible to work something into test-framework.sh that took "<tt>error_not_in_vm</tt>" with some failure rate <tt>1/R</tt>, and if the subtest failed it would automatically set <tt>ONLY_REPEAT</tt> for the current test and then re-run it <tt>R</tt> times to ensure it wasn't failing more frequently. That would still have some chance of failing or missing issues, but would <em>usually</em> avoid the need for gratuitous test restarts, and be <b>more</b> likely to catch changes in intermittent failures than developers are... </p> Related Development Rank 1|i00sdz: Rank (Obsolete) 9223372036854775807 Severity