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-5373 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://testing.hpdd.intel.com/test_sets/cd5613b2-0dd2-11e4-972c-5254006e85c2" class="external-link" target="_blank" rel="nofollow noopener">https://testing.hpdd.intel.com/test_sets/cd5613b2-0dd2-11e4-972c-5254006e85c2</a>.</p> <p>The sub-test test_33b failed with the following error:</p> <blockquote> <p>test_33b failed with 2</p></blockquote> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>== sanity test 33b: test open file with malformed flags (No panic) =================================== 18:24:17 (1405473857) running as uid/gid/euid/egid 500/500/500/500, groups: [openfile] [-f] [1286739555] [/mnt/lustre/d33/f33] Error in opening file "/mnt/lustre/d33/f33"(flags=1286739555) 2: No such file or directory sanity test_33b: @@@@@@ FAIL: test_33b failed with 2 </pre> </div></div> server: lustre-b2_6-rc2 RHEL6 ldiskfs<br/> client: SLES11 SP3 LU-5373

Failure on test suite sanity test_33b: FAIL: test_33b failed with 2

Bug Major Resolved Fixed Bob Glossman Maloo Fri, 18 Jul 2014 22:22:33 +0000 Fri, 16 Jan 2015 18:58:51 +0000 Fri, 16 Jan 2015 18:58:51 +0000 Lustre 2.6.0 Lustre 2.7.0 0 7 <p>So mkdir and chown worked fine and yet later file creation in that dir failed? That's kind of strange.</p> <p>another instance:<br/> <a href="https://testing.hpdd.intel.com/test_sets/59550492-3329-11e4-bf24-5254006e85c2" class="external-link" target="_blank" rel="nofollow noopener">https://testing.hpdd.intel.com/test_sets/59550492-3329-11e4-bf24-5254006e85c2</a></p> <p>this is also with sles11sp3 client. I wonder if this is only seen on sles11sp3.</p> <p>it'd seen here with el7 client<br/> <a href="https://testing.hpdd.intel.com/test_sets/06458494-2fc7-11e4-957a-5254006e85c2" class="external-link" target="_blank" rel="nofollow noopener">https://testing.hpdd.intel.com/test_sets/06458494-2fc7-11e4-957a-5254006e85c2</a></p> <p>seen again in master, el7 client:<br/> <a href="https://testing.hpdd.intel.com/test_sets/31a088ae-6c81-11e4-8bd3-5254006e85c2" class="external-link" target="_blank" rel="nofollow noopener">https://testing.hpdd.intel.com/test_sets/31a088ae-6c81-11e4-8bd3-5254006e85c2</a></p> <p>I'm starting to think this test is invalid in kernels newer than 2.6. I see consistent, repeatable failures in any manual invocation of openfile with any illegal combination of open flags. The set of illegal flags in test 33b is just one example. I see similar errors with opens not on lustre, in /tmp or other directories. It always fails and returns ENOENT. This is seen in sles11sp3 (3.0 kernels), sles12 (3.12 kernels), and el7 (3.10 kernels).</p> <p>Strongly suspect generic open code is more picky about open flags in newer kernels and is returning an error before ever reaching lustre.</p> <p>Bob, is this just a matter of fixing the test to ignore the return code of this test? The test comment is "no panic", which we would detect via "/proc/sys/lnet/catastrophe", so it might be enough to add "|| true" at the end.</p> <p>Andreas, yes you are correct. I think it may be as simple as teaching the test to ignore the return value of $OPENFILE command. As far as I can tell this test is just trying to see a panic doesn't happen, it doesn't really care of the command succeeds or not. Or at least it shouldn't care.</p> <p>I'm just wondering if it's even worth it to keep this test around. I've never seen it actually cause the panic it's checking against. Suspect it went in a long time ago to look for a problem that was fixed a long time ago.</p> <p>Bob Glossman (bob.glossman@intel.com) uploaded a new patch: <a href="http://review.whamcloud.com/12992" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/12992</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-5373" title="Failure on test suite sanity test_33b: FAIL: test_33b failed with 2 " class="issue-link" data-issue-key="LU-5373"><del>LU-5373</del></a> test: ignore command return value in sanity test_33b<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 8eb4a5d72b3bfbe4febc921391da0fbb329832e8</p> <p>following Andreas' suggestion I've pushed a simple fix that just ignores the command return value. If anybody objects to this solution please add a review comment.</p> <p>Still think it might be better to just delete the test since it doesn't seem to be testing anything useful.</p> <p>Bob, I'd prefer to keep the test around. The whole point of a test that always passes is that you know when it fails in the future. </p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/12992/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/12992/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-5373" title="Failure on test suite sanity test_33b: FAIL: test_33b failed with 2 " class="issue-link" data-issue-key="LU-5373"><del>LU-5373</del></a> test: ignore command return value in sanity test_33b<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 9b1569f56a1504e89e29c769900fedcbaad4abe7</p> <p>Patch landed to Master.</p> Development Rank 1|hzwrtb: Rank (Obsolete) 14978 Severity