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-5105 Lustre <p>This issue was created by maloo for Nathaniel Clark &lt;nathaniel.l.clark@intel.com&gt;</p> <p>This issue relates to the following test suite run: <a href="http://maloo.whamcloud.com/test_sets/6c3d597e-e351-11e3-93d9-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">http://maloo.whamcloud.com/test_sets/6c3d597e-e351-11e3-93d9-52540035b04c</a>.</p> <p>The sub-test test_18d failed with the following error:</p> <blockquote> <p>test failed to respond and timed out</p></blockquote> <p>Info required for matching: sanity-lfsck 18d</p> <p>MDS syslog:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>umount D 0000000000000000 0 19510 19509 0x00000080 ffff880051eaf8b8 0000000000000082 0000000000000000 ffff880051eaf87c 0000000000000282 0000000000000282 ffff880051eaf858 ffffffff8108410c ffff8800554de5f8 ffff880051eaffd8 000000000000fbc8 ffff8800554de5f8 Call Trace: [&lt;ffffffff8108410c&gt;] ? lock_timer_base+0x3c/0x70 [&lt;ffffffff815291c2&gt;] schedule_timeout+0x192/0x2e0 [&lt;ffffffff81084220&gt;] ? process_timeout+0x0/0x10 [&lt;ffffffff8152932e&gt;] schedule_timeout_uninterruptible+0x1e/0x20 [&lt;ffffffffa123ddea&gt;] dnode_special_close+0x2a/0x60 [zfs] [&lt;ffffffffa1232652&gt;] dmu_objset_evict+0x92/0x400 [zfs] [&lt;ffffffffa1243c50&gt;] dsl_dataset_evict+0x30/0x1b0 [zfs] [&lt;ffffffffa1223dd9&gt;] dbuf_evict_user+0x49/0x80 [zfs] [&lt;ffffffffa1225087&gt;] dbuf_rele_and_unlock+0xf7/0x1e0 [zfs] [&lt;ffffffffa12254e0&gt;] dmu_buf_rele+0x30/0x40 [zfs] [&lt;ffffffffa1249170&gt;] dsl_dataset_disown+0xb0/0x1d0 [zfs] [&lt;ffffffffa1231751&gt;] dmu_objset_disown+0x11/0x20 [zfs] [&lt;ffffffffa18f690e&gt;] udmu_objset_close+0x2e/0x40 [osd_zfs] [&lt;ffffffffa18f4f86&gt;] osd_device_fini+0x366/0x5c0 [osd_zfs] [&lt;ffffffffa0d9dd53&gt;] class_cleanup+0x573/0xd30 [obdclass] [&lt;ffffffffa0d757a6&gt;] ? class_name2dev+0x56/0xe0 [obdclass] [&lt;ffffffffa0d9fa7a&gt;] class_process_config+0x156a/0x1ad0 [obdclass] [&lt;ffffffffa0d97d53&gt;] ? lustre_cfg_new+0x2d3/0x6e0 [obdclass] [&lt;ffffffffa0da0159&gt;] class_manual_cleanup+0x179/0x6f0 [obdclass] [&lt;ffffffffa0d73c7b&gt;] ? class_export_put+0x10b/0x2c0 [obdclass] [&lt;ffffffffa18f412d&gt;] osd_obd_disconnect+0x1bd/0x1c0 [osd_zfs] [&lt;ffffffffa0da273b&gt;] lustre_put_lsi+0x1ab/0x11a0 [obdclass] [&lt;ffffffffa0daacf8&gt;] lustre_common_put_super+0x5d8/0xbe0 [obdclass] [&lt;ffffffffa0dd8c70&gt;] server_put_super+0x180/0xe40 [obdclass] [&lt;ffffffff8118b31b&gt;] generic_shutdown_super+0x5b/0xe0 [&lt;ffffffff8118b406&gt;] kill_anon_super+0x16/0x60 [&lt;ffffffffa0da2016&gt;] lustre_kill_super+0x36/0x60 [obdclass] [&lt;ffffffff8118bba7&gt;] deactivate_super+0x57/0x80 [&lt;ffffffff811aabdf&gt;] mntput_no_expire+0xbf/0x110 [&lt;ffffffff811ab72b&gt;] sys_umount+0x7b/0x3a0 </pre> </div></div> LU-5105

Test failure sanity-lfsck test_18d: umount mds hung

Bug Minor Resolved Won't Fix nasf Nathaniel Clark zfs Tue, 27 May 2014 14:23:48 +0000 Fri, 23 Oct 2015 14:45:41 +0000 Fri, 23 Oct 2015 14:45:41 +0000 Lustre 2.6.0 0 4 <p>Another failure instance:<br/> <a href="https://testing.hpdd.intel.com/test_sets/adb9bee6-4b17-11e4-941e-5254006e85c2" class="external-link" target="_blank" rel="nofollow noopener">https://testing.hpdd.intel.com/test_sets/adb9bee6-4b17-11e4-941e-5254006e85c2</a></p> <p>For the failures in <a href="https://testing.hpdd.intel.com/test_sets/adb9bee6-4b17-11e4-941e-5254006e85c2:" class="external-link" target="_blank" rel="nofollow noopener">https://testing.hpdd.intel.com/test_sets/adb9bee6-4b17-11e4-941e-5254006e85c2:</a><br/> sanity-lfsck test_18c failure is another instance of <a href="https://jira.whamcloud.com/browse/LU-5848" title="sanity-lfsck test_18e: MDS is not the expected &#39;completed&#39; " class="issue-link" data-issue-key="LU-5848"><del>LU-5848</del></a>. test_18d hung when umount the mds4 because the former lfsck assistant thread for test_18c was blocked at dt_sync(), so it is the side effect of test_18c failure (<a href="https://jira.whamcloud.com/browse/LU-5848" title="sanity-lfsck test_18e: MDS is not the expected &#39;completed&#39; " class="issue-link" data-issue-key="LU-5848"><del>LU-5848</del></a>), not the same as the original ZFS based test_18d hung in <a href="http://maloo.whamcloud.com/test_sets/6c3d597e-e351-11e3-93d9-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">http://maloo.whamcloud.com/test_sets/6c3d597e-e351-11e3-93d9-52540035b04c</a>.</p> <p>Alex, do you have any idea about umount MDS hung for ZFS based backend?<br/> <a href="https://testing.hpdd.intel.com/test_sets/6c3d597e-e351-11e3-93d9-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">https://testing.hpdd.intel.com/test_sets/6c3d597e-e351-11e3-93d9-52540035b04c</a></p> <p>well, in that specific case it looks like some dnode was still referenced:<br/> Call Trace:<br/> <span class="error">&#91;&lt;ffffffff8108410c&gt;&#93;</span> ? lock_timer_base+0x3c/0x70<br/> <span class="error">&#91;&lt;ffffffff815291c2&gt;&#93;</span> schedule_timeout+0x192/0x2e0<br/> <span class="error">&#91;&lt;ffffffff81084220&gt;&#93;</span> ? process_timeout+0x0/0x10<br/> <span class="error">&#91;&lt;ffffffff8152932e&gt;&#93;</span> schedule_timeout_uninterruptible+0x1e/0x20<br/> <span class="error">&#91;&lt;ffffffffa123ddea&gt;&#93;</span> dnode_special_close+0x2a/0x60 <span class="error">&#91;zfs&#93;</span><br/> <span class="error">&#91;&lt;ffffffffa1232652&gt;&#93;</span> dmu_objset_evict+0x92/0x400 <span class="error">&#91;zfs&#93;</span><br/> <span class="error">&#91;&lt;ffffffffa1243c50&gt;&#93;</span> dsl_dataset_evict+0x30/0x1b0 <span class="error">&#91;zfs&#93;</span><br/> <span class="error">&#91;&lt;ffffffffa1223dd9&gt;&#93;</span> dbuf_evict_user+0x49/0x80 <span class="error">&#91;zfs&#93;</span><br/> <span class="error">&#91;&lt;ffffffffa1225087&gt;&#93;</span> dbuf_rele_and_unlock+0xf7/0x1e0 <span class="error">&#91;zfs&#93;</span><br/> <span class="error">&#91;&lt;ffffffffa12254e0&gt;&#93;</span> dmu_buf_rele+0x30/0x40 <span class="error">&#91;zfs&#93;</span><br/> <span class="error">&#91;&lt;ffffffffa1249170&gt;&#93;</span> dsl_dataset_disown+0xb0/0x1d0 <span class="error">&#91;zfs&#93;</span><br/> <span class="error">&#91;&lt;ffffffffa1231751&gt;&#93;</span> dmu_objset_disown+0x11/0x20 <span class="error">&#91;zfs&#93;</span><br/> <span class="error">&#91;&lt;ffffffffa18f690e&gt;&#93;</span> udmu_objset_close+0x2e/0x40 <span class="error">&#91;osd_zfs&#93;</span><br/> <span class="error">&#91;&lt;ffffffffa18f4f86&gt;&#93;</span> osd_device_fini+0x366/0x5c0 <span class="error">&#91;osd_zfs&#93;</span></p> <p>so the metadnode can't go blocking umount.</p> <p>but this seem to be some old version? we don't have udmu wrappers anymore.</p> <p>Yes, there seems no way to know which dnode still be referenced. The original issue was hit by the patch <a href="http://review.whamcloud.com/#/c/10223/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/10223/</a>. I am not sure whether it is such patch special or not. But since such patch has been landed to master, there should be similar trouble on master branch. But it is also possible that such trouble has been fixed by other patch occasionally.</p> <p>a patch to dump referenced dnodes.</p> <p>Close it since the issue only has been reported on very old version.</p> Development Rank 1|hzwn3r: Rank (Obsolete) 14085 Severity