Need to force sync(2) before umounting UFS1 filesystems?

[Kostik Belousov]

On Tue, Oct 11, 2011 at 12:56:47AM -0700, Kirk McKusick wrote:
> > Date: Mon, 10 Oct 2011 19:12:59 -0700
> > From: Garrett Cooper <yanegomi at gmail.com>
> > To: Kostik Belousov <kostikbel at gmail.com>
> > Cc: Kirk McKusick <mckusick at mckusick.com>, Attilio Rao <attilio at freebsd.org>,
> >         Xin LI <delphij at freebsd.org>, freebsd-fs at freebsd.org
> > Subject: Re: Need to force sync(2) before umounting UFS1 filesystems?
> > 
> > 2011/10/10 Kostik Belousov <kostikbel at gmail.com>:
> > 
> > > The real case to test is the NFS mount which is wedged due to
> > > hung/unresponsive NFS server. I have high suspect that the patch
> > > could introduce the unkillable hung unmount process.
> > 
> >     It blocked, but I could ^C it perfectly fine. I tested it via:
> > 
> > Setup:
> > 1. Started up FreeNAS 8.x image; it acquired an IP from my server with
> > dhcp-75.local.
> > 
> > Test 1:
> > 1. mount -t nfs dhcp-75:/mnt/tank /mnt/nfs/ from my test workstation.
> > 2. Paused VM.
> > 3. umount /mnt/nfs (the command blocked).
> > 4. ^C.
> > 5. mount | grep /mnt/nfs showed nothing (it had unmounted).
> > 
> > Test 2:
> > 1. mount -t nfs dhcp-75:/mnt/tank /mnt/nfs/ from my test workstation (blocked).
> > 2. Opened up another ssh session and cd'ed to /mnt/nfs .
> > 3. Paused VM.
> > 4. umount /mnt/nfs . It failed with EBUSY.
> > 5. mount | grep /mnt/nfs showed that it was still mounted, as expected.
> > 
> >     So unless there are buffers still waiting to be written out to an
> > NFS share, or other reasons that would prevent the NFS share from
> > being fully released, I doubt the proposed behavior is really
> > different from previous versions of FreeBSD.
> > Thanks,
> > -Garrett
> 
> Given the testing that has been done and our discussion about deadlocks,
I am not sure that it was adequate.

If it was not obvious, my main concern is the nfs client that busied
the mount point and waiting for the wedged server rpc response.

> I believe that I should proceed to check in my originally proposed
> change. Notably the one that simply deleted the != MNT_FORCE
> conditional. However, there is no harm in using my revised version
> that releases the covered vnode before draining vfs_busy, and there
> might be some future case where that would be a necessary thing to do.
What is the future case where you intend to break the order between
vfs_busy() and vnode locks ?

> 
> Speak up if you think I should not proceed to check in this change.
> Also, let me know if you have thoughts on which version I should use.

If commmitting any of two changes, I would prefer to see the minimal one,
which does not unlock the covered vnode.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20111011/e4d939cc/attachment.pgp