[LU-3703] Failure on test suite sanity test_234: getfattr should have failed with ENOMEM

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.5.0
• Fix Version/s: Lustre 2.6.0, Lustre 2.7.0
• Type: Bug
• Priority: Minor
• Reporter: Maloo
• Assignee: Bob Glossman (Inactive)
• Resolution: Fixed

Environment

server and client: lustre-master build #1592
client is running SLES11 SP2

• Severity: 3

Description

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

This issue relates to the following test suite run: http://maloo.whamcloud.com/test_sets/f1069794-fd68-11e2-9fdb-52540035b04c.

The sub-test test_234 failed with the following error:

getfattr should have failed with ENOMEM

Info required for matching: sanity 234

Issue Links

• is related to: LU-9422 sanity test 234 is skipped incorrectl...

Comments

[Oleg Drokin]

Test output:

setfattr: /mnt/lustre/d0.sanity/d234/f.sanity.234: Cannot allocate memory
/mnt/lustre/d0.sanity/d234/f.sanity.234: user.attr: Cannot allocate memory
 sanity test_234: @@@@@@ FAIL: getfattr should have failed with ENOMEM 
  Trace dump:

So the enomem did happen.
is setfattr in SLES broken and does not return error status in this case?

[Bob Glossman (Inactive)]

setfattr is fine, it's getfattr that has the problem. The log reported by Oleg shows the setfattr command failing (as expected) but the getfattr command reporting error but then returning success. I can easily reproduce this failure on any SLES client.

I'm almost sure this is due to version skew of the getfattr commend (attr rpm). The version is 2.4.43 in SLES11 SP2, 2.4.44 in RH/Centos 6.4.

version 2.4.44 has the following fix:

author Kamil Dudka <[e-mail]> 2010-12-22 13:13:27 (GMT)
committer Andreas Gruenbacher <[e-mail]> 2011-05-27 12:26:38 (GMT)
commit 93c92ed1d826c6759bb83d2168ee818a05280f35 (patch) (side-by-side diff)
tree b0135b160603f2a4a1f2c3f16b2cbedcc0442ba3 /test/attr.test
parent 2c053e75d44016dd6b07649a356c1ce55dbe1028 (diff)
download attr-93c92ed1d826c6759bb83d2168ee818a05280f35.tar.gz
getfattr: return non-zero exit code on failure
reported by Jean-Pierre André at https://bugzilla.redhat.com/660619

Without finding, downloading, and examining the exact source of the SLES11 SP2 attr rpm I can't 100% confirm that this fix is missing there, but it seems very likely.

If this is so than this test can be expected to fail on any SLES11 SP2 client.

[Bob Glossman (Inactive)]

http://review.whamcloud.com/7306

skip the portion of the test that works incorrectly due to old getfattr version.

[Andreas Dilger]

Adding this to the list of things to check for 2.6.0, assuming that SLES fixes this problem for SLES11 SP3 or whatever.

[Bob Glossman (Inactive)]

Same getfattr version in SP3 as in SP2. SLES doesn't move to a fixed version until much later.

[Peter Jones]

Landed for 2.6

[Andreas Dilger]

Fix up the check to skip getfattr based on the actual version instead of just checking for SLES, since this also fails on my FC13 based test system at home (attr-2.4.44-3.fc13.x86_64).

http://review.whamcloud.com/10867

[Andreas Dilger]

The original patch skipped this test for all SLES systems. Reopen this bug until patch 10867 is landed that only skips the test for attr-2.4.44 so it will resume testing on newer SLES releases automatically.

[Jodi Levi (Inactive)]

Patch landed to Master.