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-3380 Lustre <p>We are observing a failure to activate one Lustre 1.8.5 target in order to run 'lfs quota -u ...'. Five OSTs have been deactivated for performance reasons, and four of five activate correctly but one (OST0008) continuously fails to activate, despite fsck'ing both the OST and the MDT. The sequence and errors are shown below. We are aware that both kernel and lustre versions are terribly old and we are in the process of getting to version 1.8.9, and then 2.1.x. Any assistance or suggestions is appreciated.</p> <p>Deactivated targets:<br/> 7 IN osc scratch1-OST0002-osc scratch1-mdtlov_UUID 5<br/> 9 IN osc scratch1-OST0004-osc scratch1-mdtlov_UUID 5<br/> 13 IN osc scratch1-OST0008-osc scratch1-mdtlov_UUID 5<br/> 15 IN osc scratch1-OST000a-osc scratch1-mdtlov_UUID 5<br/> 28 IN osc scratch1-OST0017-osc scratch1-mdtlov_UUID 5</p> <p>Attempt to activate targets on the MDS results in OST0008 remaining inactive:<br/> 13 IN osc scratch1-OST0008-osc scratch1-mdtlov_UUID 5</p> <p>Errors on OSS:<br/> 2013-05-22 12:11:45 xxxxxx <span class="error">&#91;47215.258366&#93;</span> Lustre: scratch1-OST0008: received MDS connection from xx.x.xx.x@o2ib &lt;kern.warning&gt;<br/> 2013-05-22 12:11:45 xxxxx <span class="error">&#91;47215.259576&#93;</span> LustreError: 8201:0:(filter.c:3173:filter_handle_precreate()) scratch1-OST0008: ignoring bogus orphan destroy request: obdid 15039753 last_id 15086581 &lt;kern.err&gt;</p> <p>Errors on MDS:<br/> 2013-05-22 12:11:45 xxxxx <span class="error">&#91;1792441.005047&#93;</span> LustreError: 10973:0:(osc_create.c:589:osc_create()) scratch1-OST0008-osc: oscc recovery failed: -22 &lt;kern.err&gt;<br/> 2013-05-22 12:11:45 xxxxx <span class="error">&#91;1792441.005056&#93;</span> Lustre: scratch1-OST0008_UUID: Failed to clear orphan objects on OST: -22 &lt;kern.warning&gt;<br/> 2013-05-22 12:11:45 xxxxx <span class="error">&#91;1792441.005058&#93;</span> Lustre: scratch1-OST0008_UUID: Sync failed deactivating: rc -22 &lt;kern.warning&gt;</p> Red Hat Enterprise Linux Server release 5.5 (Tikanga), Kernel 2.6.18-108redsky_chaos, Lustre:<br/> lustre: 1.8.5<br/> kernel: patchless_client<br/> build: 1.8.5-6chaos LU-3380

Failure to activate deactivated OST

Bug Major Resolved Duplicate Niu Yawei Chirstopher Beggio Wed, 22 May 2013 18:21:11 +0000 Mon, 27 May 2013 02:24:57 +0000 Mon, 27 May 2013 02:24:57 +0000 Lustre 1.8.x (1.8.0 - 1.8.5) 0 4 <p>Niu</p> <p>Could you please comment on this one?</p> <p>Thanks</p> <p>Peter</p> <p>I should add that the target has also been remounted aborting recovery (-o abort_recov) to eliminate that as a possible solution.</p> <p>It appears this problem and solution are documented in <a href="https://jira.whamcloud.com/browse/LU-2018" title="Questions about using lfsck" class="issue-link" data-issue-key="LU-2018"><del>LU-2018</del></a>. I will review and implement that fix and report the result.</p> <p>yes, it looks same problem of <a href="https://jira.whamcloud.com/browse/LU-2018" title="Questions about using lfsck" class="issue-link" data-issue-key="LU-2018"><del>LU-2018</del></a>, you need to make sure if the lov_objid on MDS or the last_id on OST is wrong, and change them correctly following the instructions described in <a href="https://jira.whamcloud.com/browse/LU-2018" title="Questions about using lfsck" class="issue-link" data-issue-key="LU-2018"><del>LU-2018</del></a>. Thanks.</p> <p>The issue was similar to <a href="https://jira.whamcloud.com/browse/LU-2018" title="Questions about using lfsck" class="issue-link" data-issue-key="LU-2018"><del>LU-2018</del></a>. The difference was that the lov_objid, last on-disk object ID, and LAST_ID were all different, and the MDT lov_objid for that OST and the on-disk last object ID for that target were very close, and the MDT lov_objid was advanced of the on-disk last object ID. The LAST_ID on the OST was way off, so I reset that to the last on-disk object ID and that corrected the issue. If this is the wrong solution to this problem, please let me know. It seems to me that the last on-disk object ID should be the gold standard, so I used that. Unless I have made an incorrect assumption, this may be closed.</p> <p>Right, we should use the last object ID as standard in this case. Thanks, Chris.</p> <p>Duplicated with <a href="https://jira.whamcloud.com/browse/LU-2018" title="Questions about using lfsck" class="issue-link" data-issue-key="LU-2018"><del>LU-2018</del></a>.</p> Development Epic/Theme Quota Rank 1|hzvrmf: Rank (Obsolete) 8366 Severity