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-7759 Lustre <p>It looks like modern distros: SLES12, Fedora 21+ (possibly earlier) always do statfs on the mountpoint before issuing the umount call.</p> <p>In case one of the OSTs is not available at that time - the statfs will hang.</p> <p>In our tests there's a bunch of tests in conf-sanity that have this problem and it was "dealt with" in <a href="https://jira.whamcloud.com/browse/LU-5472" title="conf-sanity test_32a: failed with 1" class="issue-link" data-issue-key="LU-5472"><del>LU-5472</del></a> by just adding the -f umount option.<br/> But this still leaves palces like recovery-single test 89 and something in recovery-small at the very least.</p> <p>And most of all regular users would be affected too. So I wonder if we should deal with this issue somewhat more intelligently so that the unmount does not really hang in such a case?</p> LU-7759

umount hanging in modern distros when OST is unavailable

Bug Major Resolved Fixed Yang Sheng Oleg Drokin easy sles12 Mon, 8 Feb 2016 22:53:16 +0000 Sun, 26 Nov 2017 22:01:07 +0000 Sun, 26 Nov 2017 22:01:07 +0000 Lustre 2.8.0 Lustre 2.9.0 Lustre 2.9.0 0 12 <p>One possible solution is to add a <tt>$sbin/umount.lustre</tt> script that calls <tt>lctl set_param llite.$fsname-&#42;.lazystatfs=1</tt> so that the statfs() doesn't hang? The <tt>$fsname-&#42;</tt> might be further refined to be the specific mountpoint, but I don't know offhand how to translate a mountpoint to an instance in <tt>/proc/fs/lustre</tt> and it probably isn't critical to handle the dual mount case (normally only used for testing). The <tt>$fsname</tt> part can be extracted from the device section of <tt>/proc/mounts</tt> line:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>mgsnode:/fsname mountpoint fstype options stuff </pre> </div></div> <p>I'm also not sure what the requirements for <tt>umount.lustre</tt> are, whether it is run by <tt>umount</tt> before the filesystem is unmounted, or instead of the regular <tt>umount</tt> processing?</p> <p>Yang Sheng</p> <p>Could you please look into this issue?</p> <p>Thanks</p> <p>Peter</p> <p>Looks like umount.lustre is called after statfs. Since umount need figure out fstype before invoke umount.{fstype}. This is why it call statfs.The hard part is no way to tell kernel the statfs called from umount. So avoid invoke statfs is only thing we can do. Of course, skip unavailable OST maybe a reasonable solution?</p> <p>I guess it is possible to check <tt>strstr("unmount", current-&gt;comm)</tt> and set <tt>sbi-&gt;ll_statfs |= LL_SBI_LAZYSTATFS</tt> on the filesystem, but this would add overhead to every statfs() call.</p> <p>It might be possible to set LL_SBI_LAZYSTATFS by default, but that may also cause problems with the recovery tests that wait on "df" to return to indicate recovery is complete.</p> <p>I found a way to handle it. We can add a entry to utab(default located at /run/mount/utab) when mount a lustre filesystem. Then umount will use this entry to find out fstype to avoid invoke statfs. What we need to do just change mount_lustre.c is enough. I'll produce a patch.</p> <p>Yang Sheng (yang.sheng@intel.com) uploaded a new patch: <a href="http://review.whamcloud.com/18820" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/18820</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7759" title="umount hanging in modern distros when OST is unavailable" class="issue-link" data-issue-key="LU-7759"><del>LU-7759</del></a> utils: build mount.lustre with libmount<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: ffebbb3e30c247e453480f9219985effdf035b05</p> <p>Andreas Dilger (andreas.dilger@intel.com) uploaded a new patch: <a href="http://review.whamcloud.com/19195" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/19195</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7759" title="umount hanging in modern distros when OST is unavailable" class="issue-link" data-issue-key="LU-7759"><del>LU-7759</del></a> llite: handle inactive OSTs better in statfs<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 169a33aaf665fdaef6fc5734665a04d758a443e9</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/18820/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/18820/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7759" title="umount hanging in modern distros when OST is unavailable" class="issue-link" data-issue-key="LU-7759"><del>LU-7759</del></a> utils: build mount.lustre with libmount<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: f1de339d881958de8fc47065fb31a5c8e0c14b60</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/19195/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/19195/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7759" title="umount hanging in modern distros when OST is unavailable" class="issue-link" data-issue-key="LU-7759"><del>LU-7759</del></a> llite: handle inactive OSTs better in statfs<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 23fde1f89bec0adf4f7181ccce5a236eac371a38</p> <p>Patch landed. Close ticket.</p> <p>There is a new occurrence on recent test: <a href="https://testing.hpdd.intel.com/test_sets/0d7d92de-cad2-11e7-9840-52540065bddc" class="external-link" target="_blank" rel="nofollow noopener">https://testing.hpdd.intel.com/test_sets/0d7d92de-cad2-11e7-9840-52540065bddc</a></p> <p>The test failure looks the same but not sure if they are the same.</p> <p>Rather than open up an old ticket that hasn't been seen in 2+ years, it is better to open up a new ticket for the new problem, and if they seem related they can be linked together. Otherwise, tracking the old re-opened issue fix version is more difficult than necessary.</p> Related LU-5472 LU-4039 LU-8544 LU-8731 LU-6233 LU-8069 Development Rank 1|hzy0p3: Rank (Obsolete) 9223372036854775807 Severity