From owner-freebsd-fs@FreeBSD.ORG Tue Feb 14 09:14:44 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD4F31065670 for ; Tue, 14 Feb 2012 09:14:44 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id 530FE8FC17 for ; Tue, 14 Feb 2012 09:14:42 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0Ll4mA-1SX6zH1CYY-00bOFG; Tue, 14 Feb 2012 10:14:41 +0100 Message-ID: <4F3A2600.80400@brockmann-consult.de> Date: Tue, 14 Feb 2012 10:14:40 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <627799650.1324962.1329189513227.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <627799650.1324962.1329189513227.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:0AFLWcqV5wV2m7nPXFaDffHjXQB6zV3JklW1HqlIRUM o7UAL/5HQsJhXfdksJUeGWH3n2u0HnYIO473vb6bmUl6ymJXea B0Qf0sVmTKnv3IRTwvgBk66fURSBQ1nMZL0oNNK09kl8oMWBZr Ar6TaUmv+OtFdH7G+7H5/RAnJGg6suFQIGnIHbOzw2soPebQ2O 4S+HSniMxdVXVE84vmI7M+YM/6OENUvPy9gchfX1jy55l7chM+ 2WfG/ShSbHFi/y+iw1E1/1jhgTBJKgFeaZQW9hz7hIrGn/a19q pnMIIuN569guUGPCBsk9dQid94VUUNOGb7P6HsfKM8d+l5BT6E fgefAQyXUQ4yt3qKPO9pqr7K/7ejed3HHV7wbKgBd Subject: Re: Why won't 8.2 umount -f? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 09:14:44 -0000 On 02/14/2012 04:18 AM, Rick Macklem wrote: > 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. :) >> >>> 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'. >> > I suspect that is "very difficult" to fix. The regular "umount /mnt" will > stuck somewhere inside vinvalbuf() trying to flush blocks back to the server > while holding a lock on the mount point. Although kib@ is the guy who > would most likely know, I don't think it would be easy to get it to come > out ok. For example, one approach might be to make all the sleeps interruptible > and then add code to gracefully handle an EINTR return from them and then > release locks as they return and..... well it's not something I would want > to tackle. > Lately (last 5 years or so), Linux seems to always hang or fail on "umount -f mountpoint", but there is another option "-l" which always works, even after "umount" or "umount -f" fails. I've never seen corruption from NFS using "-l", which I use often. So if it is very difficult to fix -f, why not add -l? -l Lazy unmount. Detach the filesystem from the filesystem hierarchy now, and cleanup all references to the filesystem as soon as it is not busy anymore. (Requires kernel 2.4.11 or later.) -f Force unmount (in case of an unreachable NFS system). (Requires kernel 2.1.116 or later.) And I realize they are not equivalent in all ways, but in cases of mounts that are hung and will never work again, it works the same. "cleanup ... as soon as it is not busy" probably means never clean up if it is hung, but that is similar enough to "-f". >>> 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/ > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de --------------------------------------------