[LU-5373] Failure on test suite sanity test_33b: FAIL: test_33b failed with 2

• Type: Bug
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.7.0
• Affects Version/s: Lustre 2.6.0
• Environment: server: lustre-b2_6-rc2 RHEL6 ldiskfs; client: SLES11 SP3
• Severity: 3
• Assignee: Bob Glossman (Inactive)
• Reporter: Maloo

Description

This issue was created by maloo for sarah <[e-mail]>

This issue relates to the following test suite run: https://testing.hpdd.intel.com/test_sets/cd5613b2-0dd2-11e4-972c-5254006e85c2.

The sub-test test_33b failed with the following error:

test_33b failed with 2

== 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 

Comments

[Andreas Dilger]

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.

[Bob Glossman (Inactive)]

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).

Strongly suspect generic open code is more picky about open flags in newer kernels and is returning an error before ever reaching lustre.

[Bob Glossman (Inactive)]

seen again in master, el7 client:
https://testing.hpdd.intel.com/test_sets/31a088ae-6c81-11e4-8bd3-5254006e85c2

[Minh Diep]

it'd seen here with el7 client
https://testing.hpdd.intel.com/test_sets/06458494-2fc7-11e4-957a-5254006e85c2

[Bob Glossman (Inactive)]

another instance:
https://testing.hpdd.intel.com/test_sets/59550492-3329-11e4-bf24-5254006e85c2

this is also with sles11sp3 client. I wonder if this is only seen on sles11sp3.

[Oleg Drokin]

So mkdir and chown worked fine and yet later file creation in that dir failed? That's kind of strange.