From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 02:41:14 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 29C77106566B; Tue, 14 Feb 2012 02:41:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1A63014EB5A; Tue, 14 Feb 2012 02:41:13 +0000 (UTC) Message-ID: <4F39C9C8.7060700@FreeBSD.org> Date: Mon, 13 Feb 2012 18:41:12 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: Rick Macklem References: <318799457.1320617.1329186218494.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <318799457.1320617.1329186218494.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 02:41:14 -0000 On 02/13/2012 18:23, Rick Macklem wrote: > Doug Barton wrote: >> Is there some magic I'm missing to convince an 8.2 system to umount >> -f? >> I had an NFS server crash, so I'm trying to get the mounts updated. >> All >> of the 7.x systems happily did 'umount -f', but the 8.x systems >> (mostly >> 8.2-pN) are just hanging forever. >> >> Is this a bug, or is it something I'm missing? >> > Well, I didn't realize that a 7.n system would "umount -f" an NFS > mount when the server was down and there were dirty blocks that > needed to be written back, but I don't know. I'm doubtful that any of those systems had dirty blocks. > (I seem to recall that > someone encouraged me to MFC one of my changes related to this back > to stable/7, but I'm not sure if it mattered?) Please don't unless you can verify that it doesn't make this situation worse. :) > I have pretty well fixed the new client w.r.t. this except for the > case where you do a "umount " and that gets hung. Once a non "-f" > umount gets hung, there is nothing you can do, because the mount point is > locked up, so a subsequent "umount -f" can't get as far as nfs_umount(). I'm aware of this issue, and I did 'umount -f' first. But I wonder if this isn't something that should be fixed because I think most users would expect that 'umount -> umount -f' would be the natural progression, similar to 'kill -> kill -9'. > My guess is that the old (default for 8.n) client isn't fixed for > this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it > used some in the old/regular client, but not as much as the new one. > > You also need a fairly recent (can't remember if that is in 8.2) > version of umount.c, since the code had a "sync();" at the beginning > of it that would hang before even getting to the umount(2) syscall. > > Bottom line, I think the newnfs client (the default for 9.0) can > do this, but I'm doubtful the old/reguler one can. (I also wouldn't > be surprised if there is still a bug other than the above mentioned > one w.r.t. doing a "umount /mnt" and getting that hung before trying > "umount -f /mnt". Is the new client in 8-stable up to date relevant to 9.0, and/or is it considered safe to use in production? Thanks, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/