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-1284 Lustre <p>Excution of this ACC_SM CONF_SANITY test_50<span class="error">&#91;bef&#93;</span> failed.</p> <ol> <li>ONLY=50b ACC_SM_ONLY="CONF_SANITY" NAME=ncli_nas.v3 RCLIENTS="service332" sh acceptance-small.sh</li> </ol> <p>The conf-sanity.log showed:<br/> /usr/lib64/lustre/tests/conf-sanity.sh: FAIL: test_50b import is not in DISCONN state</p> <p>When I executed against all test 50's, 50b, 50e, and 50f failed, with the same error.</p> <p>These output/debug files are attached:<br/> CONF_SANITY.output<br/> conf-sanity.log<br/> debug<br/> ogdb-service331<br/> test_logs.tgz (of subdirs of test_logs/)</p> <p>It seemed the statement below in test_50b() timed out:<br/> wait_osc_import_state mds ost DISCONN</p> <p>Tests 50b, 50e, and 50f failed on the same problem.</p> Server: centos 6.2 (2.6.32-220.4.1.el6) with Lustre 2.1.1<br/> Client: sles11sp1, running 1.8.6.81<br/> MGS/MDS uses the same device. Two OSS&#39;es. Two clients. LU-1284

CONF_SANITY test_50[bef]: FAIL: test_50b import is not in DISCONN state

Bug Minor Closed Duplicate Yang Sheng Jay Lan Wed, 4 Apr 2012 19:52:24 +0000 Tue, 10 Apr 2012 10:49:56 +0000 Tue, 10 Apr 2012 10:49:56 +0000 Lustre 2.1.1 Lustre 1.8.6 0 2 <p>The configuration file.</p> <p>Yangsheng</p> <p>Could you please help with this one?</p> <p>Thanks</p> <p>Peter</p> <p>I think this issue already fixed in <a href="https://jira.whamcloud.com/browse/LU-690" title="conf-sanity test_21a: @@@@@@ FAIL: can&#39;t put import for lustre-OST0000-osc(ost) into FULL state" class="issue-link" data-issue-key="LU-690"><del>LU-690</del></a>. It was landed on 1.8.7 &amp; 2.1.1. So 1.8.6 client is not include this change. </p> <p>Hi Yang,</p> <p>Our client is not a plain 1.8.6-wc1 release. The complete list of commits can be seen at <a href="https://github.com/jlan/lustre-nas/commits/nas-1.8.6" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/jlan/lustre-nas/commits/nas-1.8.6</a><br/> Patch of <a href="https://jira.whamcloud.com/browse/LU-690" title="conf-sanity test_21a: @@@@@@ FAIL: can&#39;t put import for lustre-OST0000-osc(ost) into FULL state" class="issue-link" data-issue-key="LU-690"><del>LU-690</del></a> did make it to the build (tag 1.8.6-5nasC).</p> <p>The server side does not have the patch, but it seems to me it does not matter.</p> <p>Hi, Jay, Do you sure MDS side doesn't included <a href="https://jira.whamcloud.com/browse/LU-690" title="conf-sanity test_21a: @@@@@@ FAIL: can&#39;t put import for lustre-OST0000-osc(ost) into FULL state" class="issue-link" data-issue-key="LU-690"><del>LU-690</del></a> change? Looks like this is a import for MDS connect to OST1, So it will cause such failed if MDS without this patch.</p> <p>Lustre: DEBUG MARKER: rpc : @@@@@@ FAIL: can't put import for osc.lustre-OST0000-osc-MDT0000.ost_server_uuid into DISCONN state after 240 sec, have CONNECTING</p> <p>Yes, the MDS side does not have the <a href="https://jira.whamcloud.com/browse/LU-690" title="conf-sanity test_21a: @@@@@@ FAIL: can&#39;t put import for lustre-OST0000-osc(ost) into FULL state" class="issue-link" data-issue-key="LU-690"><del>LU-690</del></a> fix.</p> <p>However, the <a href="https://jira.whamcloud.com/browse/LU-690" title="conf-sanity test_21a: @@@@@@ FAIL: can&#39;t put import for lustre-OST0000-osc(ost) into FULL state" class="issue-link" data-issue-key="LU-690"><del>LU-690</del></a> commit fixed lustre/tests/ost-pools.sh and lustre/tests/test-framework.sh. Both were on the test scripts, not the Lustre codes.</p> <p>Since the test was started at a client, I thought the MDS/OSS did not read ost-pool.sh or test-framework.sh, did they? If not, then the patch should not affect the MDS, I think?</p> <p>I will patch the MDS and give it a try.</p> <p>The <a href="https://jira.whamcloud.com/browse/LU-690" title="conf-sanity test_21a: @@@@@@ FAIL: can&#39;t put import for lustre-OST0000-osc(ost) into FULL state" class="issue-link" data-issue-key="LU-690"><del>LU-690</del></a> patch was landed to b1_8 and master branches only. When I tried to cherry-pick the fix from master to b2_1 tree, cherry-pick failed. The patch changes lustre/tests/ost-pools.sh and lustre/lustre/tests/test-framework.sh. The b2_1 version of ost-pools.sh is very different in test_1. I can not see how the change can fit into ost-pools.sh of v2_1.</p> <p>Is it OK to nevertheless port the changes at test-framework.sh to b_2.1 tree?</p> <p>I think it is OK. Since we just want to verify conf-sanity. </p> <p>Yeah! 50b passed with back port of <a href="https://jira.whamcloud.com/browse/LU-690" title="conf-sanity test_21a: @@@@@@ FAIL: can&#39;t put import for lustre-OST0000-osc(ost) into FULL state" class="issue-link" data-issue-key="LU-690"><del>LU-690</del></a> to 2.1.1 servers.</p> <p>Please explain to me how the changes at test-framework.sh at servers matter! I thought the client was at the driver's seat and the action to be taken at the server side was through remote lustre commands issued by the client. I thought lustre-tests scripts at server side was not executed... It seems that I was wrong?</p> <p>Hi, Jay, As my understand, Any command via 'do_nodes node command...' will run on remote node if the 'node' isn't same as local node. The PDSH must be defined to compelte this task. So if remote machine has a different test scripts it will really cause some problem. </p> <p>All test 50 subtests passed.</p> <p>The <a href="https://jira.whamcloud.com/browse/LU-690" title="conf-sanity test_21a: @@@@@@ FAIL: can&#39;t put import for lustre-OST0000-osc(ost) into FULL state" class="issue-link" data-issue-key="LU-690"><del>LU-690</del></a> needs to be back-ported to b2_1 and b2_2. Thanks for your help, Yang!</p> <p>Close as duplcated <a href="https://jira.whamcloud.com/browse/LU-690" title="conf-sanity test_21a: @@@@@@ FAIL: can&#39;t put import for lustre-OST0000-osc(ost) into FULL state" class="issue-link" data-issue-key="LU-690"><del>LU-690</del></a>.</p> Development Rank 1|hzvfb3: Rank (Obsolete) 6125 Severity