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-2635 Lustre <p>This issue was created by maloo for sarah &lt;sarah@whamcloud.com&gt;</p> <p>This issue relates to the following test suite run: <a href="https://maloo.whamcloud.com/test_sets/75c2e2be-5b55-11e2-b205-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">https://maloo.whamcloud.com/test_sets/75c2e2be-5b55-11e2-b205-52540035b04c</a>.</p> <p>The sub-test test_27d failed with the following error:</p> <blockquote> <p>setstripe failed</p></blockquote> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>== sanity test 27d: create file with default settings ================== 13:14:06 (1357334046) setstripe: invalid option -- 'S' Create a new file with a specific striping pattern or set the default striping pattern on an existing directory or delete the default striping pattern from an existing directory usage: setstripe [--size|-s stripe_size] [--count|-c stripe_count] [--index|-i|--offset|-o start_ost_index] [--pool|-p &lt;pool&gt;] &lt;directory|filename&gt; or setstripe -d &lt;directory&gt; (to delete default striping) stripe_size: Number of bytes on each OST (0 filesystem default) Can be specified with k, m or g (in KB, MB and GB respectively) start_ost_index: OST index of first stripe (-1 default) stripe_count: Number of OSTs to stripe over (0 default, -1 all) pool: Name of OST pool to use (default none) sanity test_27d: @@@@@@ FAIL: setstripe failed </pre> </div></div> server: 2.4<br/> client: 2.1.3 LU-2635

Interop 2.1.3<->2.4 failure on test suite sanity test_27d: setstripe: invalid option 'S'

Bug Blocker Closed Fixed Jian Yu Maloo LB Thu, 17 Jan 2013 14:57:44 +0000 Fri, 22 Feb 2013 01:32:24 +0000 Fri, 22 Feb 2013 01:32:13 +0000 Lustre 2.4.0 0 9 <p>2.1.3 client test script (sanity test_27d) does not use setstripe with '-S' while 2.4 test script uses. I don't know the interop test mechanism, does the test use client's test script or server's?</p> <p>Intuitively I think it should use client's test script but the test result shows the other way.</p> <p>It's the scripts on the client that get executed. However I see the following in the node-provisioning logs:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>' &gt; /root/autotest_config.sh" on client-32vm2 via client-32vm2 12:35:55: 12:35:55:Executing "mv /usr/lib64/lustre/tests /usr/lib64/lustre/tests-old" on client-32vm2 via client-32vm2 12:35:55: 12:35:55:Executing "scp -r client-32vm7:/usr/lib64/lustre/tests /usr/lib64/lustre/tests" on client-32vm2 via client-32vm2 </pre> </div></div> <p>From that it appears the test scripts from a server are being copied onto the client during provisioning. Seems like a test setup flaw to me.</p> <p>Chris,</p> <p>Could you take it a look?</p> <p>We have 2 modes.</p> <p>client runs client scripts, servers run server scripts.<br/> both run the server scripts.</p> <p>The implementation works like this, each branch has a version number.<br/> master: 5<br/> b1_8: 0<br/> b2_4: 5<br/> b2_3: 5<br/> b2_2: 0<br/> b2_1: 0</p> <p>If the versions are the same then they are compatible, if they diff then the server is copied to the client.</p> <p>2.1 2.4 being a case in question, this idea was after a discussion with Andreas.</p> <p>Shall we turn it off for know to see if that cures this problem.</p> <p>Worth turning it off for a trial. I suspect that will cure this problem, but might generate a whole set of new ones.</p> <p>If we want to continue to use server scripts on clients we will need to version check all uses of setstripe -S in server scripts. Lots more than just this one in sanity, test 27d.</p> <p>I can see the dilemma here, our client side test scripts also run remote command on MDS/OST, so when the server client scripts are not compatible, it would come to problems just running either client scripts or server scripts only.</p> <p>For this incompatible interop test, I guess this situation will be inevitable.</p> <p>We will be fixing this on b2_1.</p> <p>I triggered autotest to perform the Lustre b2_1 and master interop testing on the latest builds:<br/> Lustre b2_1 client: <a href="http://build.whamcloud.com/job/lustre-b2_1/176" class="external-link" target="_blank" rel="nofollow noopener">http://build.whamcloud.com/job/lustre-b2_1/176</a><br/> Lustre master server: <a href="http://build.whamcloud.com/job/lustre-master/1269" class="external-link" target="_blank" rel="nofollow noopener">http://build.whamcloud.com/job/lustre-master/1269</a></p> <p>sanity test 27d passed: <a href="https://maloo.whamcloud.com/test_sets/ffcd3138-7cb3-11e2-a108-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">https://maloo.whamcloud.com/test_sets/ffcd3138-7cb3-11e2-a108-52540035b04c</a></p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>== sanity test 27d: create file with default settings ================== 21:36:54 (1361511414) /mnt/lustre/d27/fdef has type file OK 4+0 records in 4+0 records out 16384 bytes (16 kB) copied, 0.00525656 s, 3.1 MB/s Resetting fail_loc on all nodes...CMD: client-19vm1.lab.whamcloud.com,client-19vm2,client-19vm3,client-19vm4 lctl set_param -n fail_loc=0 2&gt;/dev/null || true done. </pre> </div></div> <p>While fixing TT-1053, Chris has turned off the autotest feature of running server scripts on client node. So, the issue in this ticket does not exist.</p> Development Rank 1|hzvfjr: Rank (Obsolete) 6164 Severity