Date: Tue, 11 Oct 2011 14:03:56 +0200 From: Attilio Rao <attilio@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: Kirk McKusick <mckusick@mckusick.com>, Garrett Cooper <yanegomi@gmail.com>, Xin LI <delphij@freebsd.org>, freebsd-fs@freebsd.org Subject: Re: Need to force sync(2) before umounting UFS1 filesystems? Message-ID: <CAJ-FndB3mkrgnT7%2BfAyQ=mLdY==QAoA%2BeG%2BTVOoW8s19WUGXCg@mail.gmail.com> In-Reply-To: <20111011102331.GW1511@deviant.kiev.zoral.com.ua> References: <CAGH67wS%2BAW9zYnq=KQzKoVSfM5Oiax%2Bej=tfJ5BvjZHzb6zavA@mail.gmail.com> <201110110756.p9B7ul0g051037@chez.mckusick.com> <20111011102331.GW1511@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/10/11 Kostik Belousov <kostikbel@gmail.com>: > 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@gmail.com> >> > To: Kostik Belousov <kostikbel@gmail.com> >> > Cc: Kirk McKusick <mckusick@mckusick.com>, Attilio Rao <attilio@freebs= d.org>, >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Xin LI <delphij@freebsd.org>, freebsd-fs@f= reebsd.org >> > Subject: Re: Need to force sync(2) before umounting UFS1 filesystems? >> > >> > 2011/10/10 Kostik Belousov <kostikbel@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. >> > >> > =C2=A0 =C2=A0 It blocked, but I could ^C it perfectly fine. I tested i= t 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= . >> > >> > =C2=A0 =C2=A0 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 !=3D 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. I agree with Kostik, I don't see the point for dropping coveredvnode as long as the ordering is already set up, but I don't have objections to the 'minimal' change. Attilio --=20 Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndB3mkrgnT7%2BfAyQ=mLdY==QAoA%2BeG%2BTVOoW8s19WUGXCg>