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-17344 Lustre <p>A system running LFSCK was crashing in a loop, apparently trying to destroy a bad object FID:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> LustreError: 16300:0:(ldlm_resource.c:1488:ldlm_resource_get()) ASSERTION(name-&gt;name[0] != 0) failed: kernel:Kernel panic - not syncing: LBUG Call Trace: libcfs_call_trace+0x90/0xf0 [libcfs] lbug_with_loc+0x4c/0xa0 [libcfs] ldlm_resource_get+0x7e9/0x950 [ptlrpc] ldlm_lock_create+0x55/0xa60 [ptlrpc] ldlm_cli_enqueue_local+0xcc/0x850 [ptlrpc] lfsck_layout_slave_conditional_destroy [lfsck] lfsck_layout_slave_in_notify+0xa19/0xed0 [lfsck] lfsck_in_notify+0x23c/0x320 [lfsck] tgt_handle_lfsck_notify+0x5c/0x140 [ptlrpc] tgt_request_handle+0x8bf/0x18c0 [ptlrpc] ptlrpc_server_handle_request+0x253/0xc40 [ptlrpc] ptlrpc_main+0xc4a/0x1cb0 [ptlrpc] kthread+0xd1/0xe0 </pre> </div></div> <p>It probably makes sense to have <tt>lfsck_layout_slave_conditional_destroy()</tt> or a higher level check that the FID is valid before calling all the way down to <tt>ldlm_cli_enqueue_local()</tt>.</p> LU-17344

ldlm_resource_get() ASSERTION(name->name[0] != 0) failed

Bug Minor Open Unresolved Hongchao Zhang Andreas Dilger Thu, 7 Dec 2023 19:06:10 +0000 Fri, 29 Dec 2023 08:54:20 +0000 Lustre 2.14.0 Lustre 2.16.0 Lustre 2.15.0 0 5 <p>Hongchao, could you please take a look into this. It looks like a relatively simple patch in <tt>lfsck_layout_slave_conditional_destroy()</tt> to check that the FID is valid before calling down the stack to "destroy" this bad object.</p> <p>It looks like this crash was on the OST side (<tt>lfsck_layout_slave_in_notify()</tt>) so it makes sense to handle this case if there is bad data sent from the MDS, but it would likely <b>also</b> make sense to add a check on the MDS side of LFSCK so that it doesn't even <b>send</b> the request to destroy an object that doesn't exist (e.g. FID <tt>0x0:0x0:0x0</tt> or similar) that is coming from a bad file layout on disk.</p> <p>Probably also changing <tt>ldlm_resource_get()</tt> to print and return an error instead of <tt>LASSERT()</tt> would make the code more robust, though harder to debug in the future.</p> <p>Hi,<br/> The FID had seemed to parsed correctly and the corresponding <b>dt_object</b> had been returned successfully and<br/> the existance of the <b>dt_object</b> already been verified, then is it possible that the issue is related to the conversion<br/> between <b>ost_id</b> and <b>lu_fid</b> for some special FID? how about adding some corresponding check here?<br/> Thanks</p> <p>"Hongchao Zhang &lt;hongchao@whamcloud.com&gt;" uploaded a new patch: <a href="https://review.whamcloud.com/c/fs/lustre-release/+/53565" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/c/fs/lustre-release/+/53565</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-17344" title="ldlm_resource_get() ASSERTION(name-&gt;name[0] != 0) failed" class="issue-link" data-issue-key="LU-17344">LU-17344</a> lfsck: check the validity of the res_id<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 23b263a28ff0b60f9f0674959fc9cb439cb84e71</p> Related Development Rank 1|i0449j: Rank (Obsolete) 9223372036854775807 Severity