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-3703 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="http://maloo.whamcloud.com/test_sets/f1069794-fd68-11e2-9fdb-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">http://maloo.whamcloud.com/test_sets/f1069794-fd68-11e2-9fdb-52540035b04c</a>.</p> <p>The sub-test test_234 failed with the following error:</p> <blockquote> <p>getfattr should have failed with ENOMEM</p></blockquote> <p>Info required for matching: sanity 234</p> server and client: lustre-master build #1592 <br/> client is running SLES11 SP2 LU-3703

Failure on test suite sanity test_234: getfattr should have failed with ENOMEM

Bug Minor Resolved Fixed Bob Glossman Maloo Mon, 5 Aug 2013 21:49:02 +0000 Mon, 1 May 2017 16:55:34 +0000 Wed, 11 Feb 2015 17:23:47 +0000 Lustre 2.5.0 Lustre 2.6.0 Lustre 2.7.0 0 7 <p>Test output:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>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: </pre> </div></div> <p>So the enomem did happen.<br/> is setfattr in SLES broken and does not return error status in this case?</p> <p>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.</p> <p>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.</p> <p>version 2.4.44 has the following fix:</p> <p>author Kamil Dudka &lt;kdudka@redhat.com&gt; 2010-12-22 13:13:27 (GMT)<br/> committer Andreas Gruenbacher &lt;agruen@linbit.com&gt; 2011-05-27 12:26:38 (GMT)<br/> commit 93c92ed1d826c6759bb83d2168ee818a05280f35 (patch) (side-by-side diff)<br/> tree b0135b160603f2a4a1f2c3f16b2cbedcc0442ba3 /test/attr.test<br/> parent 2c053e75d44016dd6b07649a356c1ce55dbe1028 (diff)<br/> download attr-93c92ed1d826c6759bb83d2168ee818a05280f35.tar.gz<br/> getfattr: return non-zero exit code on failure<br/> reported by Jean-Pierre André at <a href="https://bugzilla.redhat.com/660619" class="external-link" target="_blank" rel="nofollow noopener">https://bugzilla.redhat.com/660619</a></p> <p>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.</p> <p>If this is so than this test can be expected to fail on any SLES11 SP2 client.</p> <p><a href="http://review.whamcloud.com/7306" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7306</a></p> <p>skip the portion of the test that works incorrectly due to old getfattr version.</p> <p>Adding this to the list of things to check for 2.6.0, assuming that SLES fixes this problem for SLES11 SP3 or whatever.</p> <p>Same getfattr version in SP3 as in SP2. SLES doesn't move to a fixed version until much later.</p> <p>Landed for 2.6</p> <p>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).</p> <p><a href="http://review.whamcloud.com/10867" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/10867</a></p> <p>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.</p> <p>Patch landed to Master.</p> Related LU-9422 Development Rank 1|hzvx7r: Rank (Obsolete) 9552 Severity