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-2602 Lustre <p>This test is IGNORED. <br/> recovery-small test_24b: @@@@@@ IGNORE (bzmultiop didn't fail fsync: 5 or close: 0):<br/> ...</p> <p>Is this result expected?<br/> Also, the test log was badly corrupted.</p> <p>Test logs tarball is attached.</p> Server: 2.1.3-1nasS, centos 6.3, 2.6.32_279.2.1.el6<br/> Client: 2.1.3-SP2_1nasC_ofed154, sles11sp2, 3.0.51-0.7.9.1.20130104.<br/> 1 mds (S337), 2 oss (S361, S362), 2 clients (S331, S332)<br/> <br/> LU-2602

test: recovery-small 24b: test IGNORED and test log badly corrupted

Bug Minor Resolved Cannot Reproduce Bob Glossman Jay Lan Thu, 10 Jan 2013 15:39:25 +0000 Wed, 12 Mar 2014 00:32:07 +0000 Wed, 12 Mar 2014 00:32:07 +0000 Lustre 2.4.0 Lustre 2.1.3 Lustre 2.4.0 0 6 <p>Bob</p> <p>Could you please look into this one?</p> <p>Thanks</p> <p>Peter</p> <p>Jay, I'm a little confused. You say your client is 2.1.3, but as far as I can see the 2.1.3 version of recovery-small doesn't even have test 24b. It only has test_24.</p> <p>I'm guessing that the bad log comes from the error_ignore function being called with the wrong number of arguments. It's supposed to be 'error_ignore bug-number error-string', but instead it seems to be just 'error_ignore string' in test 24b. This could also account for weird stuff in the log.</p> <p>I suspect this isn't seen a lot as the multiop command usually fails as it's supposed to in this test.</p> <p>To check this out could you just edit your recovery-small.sh script, add any number (12345 will do) as the first argument to the error_ignore line near the end of test_24b, run the test again and see what happens?</p> <p>Bob, I hit this problem with lustre client 2.3.0-2nasC, sles11sp2, 3.0.42_0.7.3 also.</p> <p>Please ignore the 2.1.3-SP2_1nasC_ofed154 client for sles11sp2. It is not a supported version.</p> <p>That makes more sense. definitely a test 24b in 2.3 and newer versions of recovery-small. looks like the bogus error_ignore call is there too.</p> <p>Sorry, spoke too soon. Just checked the tree. The 2.3 release version of the script still only has test 24. Only newer builds like current master will have 24b. The relevant change went in ~10/30/2012</p> <p>Bob, add '12345' as the first argument did not help. However, if I change '12345' to '5494', the number used in 24a, then I got a clean log. I guess probably 12345 not a valid bug number?</p> <p>My git repo is at <a href="https://github.com/jlan/lustre-nas" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/jlan/lustre-nas</a>,<br/> with nas-2.3.0 branch and 2.3.0-2nasC tag. It is newer than wc-2.1.3 release by cherry-picking some commits from b2_1 branch.</p> <p>Thanks for going the extra mile. I think you have verified that the form of the error_ignore call is causing the problem. Knowing that I can do a 1 line fix.</p> <p>Not sure why it didn't like 12345. At first blush it seems like any number would be OK. There are examples of error_ignore calls with other 5 digit numbers in various scripts.</p> <p>Blame on commit cb102ce, which I picked up while picking up fix for <a href="https://jira.whamcloud.com/browse/LU-921" title="generate warnings in case of discarding dirty pages" class="issue-link" data-issue-key="LU-921"><del>LU-921</del></a> we requested. <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>fix in <a href="http://review.whamcloud.com/4995" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4995</a></p> <p>Hit this issue in lustre-master tag-2.3.59 ofd build testing <br/> <a href="https://maloo.whamcloud.com/test_sets/c092e582-62c6-11e2-982f-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">https://maloo.whamcloud.com/test_sets/c092e582-62c6-11e2-982f-52540035b04c</a></p> <p>server/client lustre-master build# 1176 ofd build </p> <p>Was the failure reported by Sarah Liu reproducible? It not, it is not caused by commit checked in on <a href="http://review.whamcloud.com/4995" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4995</a>.</p> <p>If this did not cause side effect, can we close this ticket? </p> <p>Jay, Looking back in the failure history of this subtest I don't see any similar failures since 1/26. I'm willing to close the ticket if it's OK with you.</p> <p>Yes, let's close it. Thanks!</p> <p>Test case 24b should be excluded for ldiskfs as well. It has tons of race and timing issue to make it fail. For example, the evict can happen before processes write the data; and "dirty page discard" can be skipped from dmesg occasionally; and the write can succeed before eviction if there is no grant on client because it will be finished with SYNC write.</p> <p>Customer indicated that we can 'close' this issue.<br/> ~ jfc.</p> Development Rank 1|hzveyv: Rank (Obsolete) 6069 Severity