From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 03:13:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 131C1106564A; Tue, 14 Feb 2012 03:13:31 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 925378FC12; Tue, 14 Feb 2012 03:13:30 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EACLQOU+DaFvO/2dsb2JhbAA7CIUQrB6BcgEBBAEjBFIbGAICDQgCDwJZBogPp0KSHYEvh2mCPggKBgUHARgNAQICCAMOBAYDBQwVAoM7gS0CgXSBFgSISoxokwI X-IronPort-AV: E=Sophos;i="4.73,414,1325480400"; d="scan'208";a="159429863" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 13 Feb 2012 22:13:29 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 80EC1B3F33; Mon, 13 Feb 2012 22:13:29 -0500 (EST) Date: Mon, 13 Feb 2012 22:13:29 -0500 (EST) From: Rick Macklem To: Doug Barton Message-ID: <2040914240.1324793.1329189209494.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4F39C9C8.7060700@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) 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 03:13:31 -0000 Doug Barton wrote: > 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. :) > sbruno did the MFC. I don't think the changes would make it 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. > > I just looked and at least some of the fixes were MFC'd to stable/8 about 8months ago. So, they aren't in 8.2, but will be in 8.3. > > 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? > It looks like stable/8 might be ok using either client. The newnfs in stable/8 should be up to date w.r.t. bugfixes in the new/regular client in 9.0. > > 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/