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-3472 Lustre <p>Here is a testcase<br/> flock -e /mnt/lustre/ff -c 'sleep 10' &amp;<br/> sleep 1<br/> flock -e /mnt/lustre/ff -c 'sleep 5' &amp;<br/> sleep 1<br/> echo "umount -f /mnt/mds1"<br/> umount -f /mnt/mds1 || true<br/> killall flock<br/> ps ax<br/> echo "umount -f /mnt/lustre"<br/> umount -f /mnt/lustre || true<br/> cleanupall -f || error "cleanup failed"</p> LU-3472

MDS can't umount with blocked flock

Bug Minor Resolved Low Priority Bruno Faccini Andriy Skulysh patch Fri, 14 Jun 2013 10:08:32 +0000 Thu, 9 Jan 2020 07:06:59 +0000 Thu, 9 Jan 2020 07:06:59 +0000 0 3 <p>patch: <a href="http://review.whamcloud.com/6647" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6647</a></p> <p>Xyratex-bug-id: MRP-997</p> <p>I think this is only a timing issue due to the time needed to give-up/time-out the FL_UNLCK attempt during the kill or exit of flock cmds. If you just wait/sleep a few seconds before trying to umount from the Client side or simply retry, you will succeed.</p> <p>Bruno, I thought you were already working on a patch to clean up FLOCK locks at unmount time?</p> <p>Andreas, I am sure you refer to <a href="https://jira.whamcloud.com/browse/LU-2665" title="LBUG while unmounting client" class="issue-link" data-issue-key="LU-2665"><del>LU-2665</del></a>, but scenario in this ticket is different since the problem there is that the FL_UNLCK request upon kill/exit of process with a granted FLOCK can be trashed when MDS communications occur leaving an orphan lock finally causing an LBUG during later umount. This is a Client-side problem requiring more robust error handling during FLock cleanup.</p> <p>About this ticket's problem, I just ran the reproducer and found that a 2nd/later umount is successful.<br/> I will try to investigate further and fully understand what's going on.</p> <p>I restarted auto-test on patch-set #2 since it triggered <a href="https://jira.whamcloud.com/browse/LU-3230" title="conf-sanity fails to start run: umount of OST fails" class="issue-link" data-issue-key="LU-3230"><del>LU-3230</del></a> problem/hang during zfs-review/replay-single/test_90.</p> <p>Hello, Andriy,<br/> Have you been able to verify the result of your patch ? Sorry to ask, but running with it, I still get the EBUSY on 1st "umount -f /mnt/lustre" ...<br/> I am working on this now to understand what's going wrong.</p> <p>So definitely, even with patch (that I agree fixes some coding imbalance and add consistency in calling ldlm_flock_blocking_unlink() from ldlm_resource_unlink_lock()!), there is still some timing/asynchronous side effect on Client during FLock cleanup that cause this. Since "killall" works same way (unless man use its -w option), in your reproducer it can not serialize enough to allow a successful 1st Client umount. May be I am wrong and missed something (tell me!), but I don't think we can fix this, it looks just like to ask for I/Os to be complete when sync() just returns.</p> <p>Close old bug</p> Development Rank 1|hzvtdj: Rank (Obsolete) 8700 Severity