From owner-freebsd-current Mon Jun 1 16:07:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02751 for freebsd-current-outgoing; Mon, 1 Jun 1998 16:07:42 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA02728 for ; Mon, 1 Jun 1998 16:07:32 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id HAA11791; Tue, 2 Jun 1998 07:06:32 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199806012306.HAA11791@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Mikhail Teterin cc: current@FreeBSD.ORG Subject: Re: NFS discovery In-reply-to: Your message of "Mon, 01 Jun 1998 17:16:19 -0400." <199806012116.RAA20073@xxx.video-collage.com> Date: Tue, 02 Jun 1998 07:06:32 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mikhail Teterin wrote: > Peter Wemm once stated: > > =That's because umount (in it's infinite wisdom) tries to stat() the > =argument to see what file type (/dev node) or directory it is (and resolve > =symlinks and other wierd things). This causes the NFS hang. > > If the client is SGI, it is possible to drop the dead mount with > > umount server:/server/path > if > umount /client/path > hangs. > > I'm glad to see someone else agreeing here. It seems incredibly stupid > if a reboot is required to get rid of the hanging nfs mount point. This is basically what we do, except that umount won't automatically break filesystem semantics of a pending operation, you have to force it with -f as converting open files to dead vnodes is pretty rude to say the least. ie: umount -f server:/server/path (I use the "-t nfs" out of habit). I don't think that anybody is saying that what we've got now is ideal. It will all be fixed very soon, it's just that there are some more pressing problems to deal with yet, and things like random data corruption are generally more destructive than unmount hangs. Not by far, mind you - having to reboot a client and loose in-transit data isn't nice either. Problems like the client not recovering after the server has come back are high on the list. We've got a fair few other really ugly problems in the PR database still. Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message