Date: Tue, 11 Oct 2011 13:23:31 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Kirk McKusick <mckusick@mckusick.com> Cc: Garrett Cooper <yanegomi@gmail.com>, Attilio Rao <attilio@freebsd.org>, Xin LI <delphij@freebsd.org>, freebsd-fs@freebsd.org Subject: Re: Need to force sync(2) before umounting UFS1 filesystems? Message-ID: <20111011102331.GW1511@deviant.kiev.zoral.com.ua> In-Reply-To: <201110110756.p9B7ul0g051037@chez.mckusick.com> References: <CAGH67wS%2BAW9zYnq=KQzKoVSfM5Oiax%2Bej=tfJ5BvjZHzb6zavA@mail.gmail.com> <201110110756.p9B7ul0g051037@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Y2BITh8TegacRQ/d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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@freebsd= .org>, > > Xin LI <delphij@freebsd.org>, freebsd-fs@freebsd.org > > Subject: Re: Need to force sync(2) before umounting UFS1 filesystems? > >=20 > > 2011/10/10 Kostik Belousov <kostikbel@gmail.com>: > >=20 > > > 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. > >=20 > > It blocked, but I could ^C it perfectly fine. I tested it via: > >=20 > > Setup: > > 1. Started up FreeNAS 8.x image; it acquired an IP from my server with > > dhcp-75.local. > >=20 > > 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). > >=20 > > Test 2: > > 1. mount -t nfs dhcp-75:/mnt/tank /mnt/nfs/ from my test workstation (b= locked). > > 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. > >=20 > > 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 >=20 > 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 ? >=20 > 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. --Y2BITh8TegacRQ/d Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6UGSMACgkQC3+MBN1Mb4ivDQCgj68AvEPpR7R91lqUxwaangpI /pwAoNuKrFsFj7uEB86btnHHvrXKjSQZ =MY9v -----END PGP SIGNATURE----- --Y2BITh8TegacRQ/d--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111011102331.GW1511>