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-5921 Lustre <p>This issue was created by maloo for nasf &lt;fan.yong@intel.com&gt;</p> <p>This issue relates to the following test suite run: <a href="https://testing.hpdd.intel.com/test_sets/078fe42c-6b6b-11e4-b1b4-5254006e85c2" class="external-link" target="_blank" rel="nofollow noopener">https://testing.hpdd.intel.com/test_sets/078fe42c-6b6b-11e4-b1b4-5254006e85c2</a>.</p> <p>The sub-test test_41c failed with the following error:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>unexpected concurent OST mounts result, rc=0 rc2=1 </pre> </div></div> <p>Please provide additional information about the failure here.</p> <p>Info required for matching: conf-sanity 41c</p> LU-5921

conf-sanity test_41c: unexpected concurent OST mounts result, rc=0 rc2=1

Bug Minor Resolved Fixed Bruno Faccini Maloo Fri, 14 Nov 2014 00:55:50 +0000 Fri, 21 Apr 2017 14:17:40 +0000 Wed, 9 Dec 2015 04:51:18 +0000 Lustre 2.8.0 0 8 <p>Bruno, it isn't clear that this should be considered a test failure. I think any result where one mount succeeds and the other fails should be considered a PASS?</p> <p>Also, it seems to me that this would be better with OBD_FAIL_RACE() instead of having the test clear the fail_loc before the second mount. Since the test is running in a VM that may be quite slow, this opens up the possibility of the first mount completing, and the second one just refuses to mount in mount.lustre because it sees the first filesystem has finished mounting.</p> <p>Hello Andreas,<br/> I am sorry but I am not completely sure about what you mean by "this would be better with OBD_FAIL_RACE() instead of having the test clear the fail_loc before the second mount" ? Do you think that I better have to use the "OBD_RACE(OBD_FAIL_TGT_CONN_RACE);" capability at the beginning of target_handle_connect(), instead to set/unset OBD_FAIL_TGT_DELAY_CONNECT to have 1st mount stall 10s and try to force a race?</p> <p>OTOH, I may also change conf-sanity/test_41c to only check that only one of both concurrent mounts fails regardless of its return code ?</p> <p>Sorry, I meant OBD_RACE() might be better than waiting in userspace. That depends on whether you actually want the two processes to race or just to have one in the middle of mounting when the second one starts.</p> <p>Faccini Bruno (bruno.faccini@intel.com) uploaded a new patch: <a href="http://review.whamcloud.com/17302" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/17302</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-5921" title="conf-sanity test_41c: unexpected concurent OST mounts result, rc=0 rc2=1" class="issue-link" data-issue-key="LU-5921"><del>LU-5921</del></a> tests: enhance server target mount race testing<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: ec9a588356c09d83e9cb3d9d385fb9ef200edf1e</p> <p>I have pushed patch #17302, to better set a concurrent/racy situation for same server target mount, and also allow to handle all mount errors instead of only EALREADY.</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/17302/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/17302/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-5921" title="conf-sanity test_41c: unexpected concurent OST mounts result, rc=0 rc2=1" class="issue-link" data-issue-key="LU-5921"><del>LU-5921</del></a> tests: enhance server target mount race testing<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 5023ca334069950ccece06db3c12104232b5ab71</p> <p>Landed for 2.8</p> Duplicate Related LU-5299 LU-8168 LU-7442 Development Rank 1|hzx0xj: Rank (Obsolete) 16528 Severity