Date: Sun, 18 Oct 1998 20:48:29 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dg@root.com Cc: tlambert@primenet.com, green@zone.syracuse.NET, grog@lemis.com, julian@whistle.com, mike@smith.net.au, bag@sinbin.demos.su, rock@cs.uni-sb.de, current@FreeBSD.ORG Subject: Re: -current NFS problem Message-ID: <199810182048.NAA10205@usr07.primenet.com> In-Reply-To: <199810160139.SAA22337@implode.root.com> from "David Greenman" at Oct 15, 98 06:39:34 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Actually that's not true. I can't speak for all of the NFS implementations > above, but at least in BSD/OS, it works only because they have warts all over > the place to sidestep the problems with not having FS node locking. OK, after having spent several hours trying to see what you mean here, I'm having a hard time understanding why locking the vnode that holds the pointer to the nfsnode data is not an implicit lock on the underlying nfsnode, just as it is for all other data that the vnode references. I can see a couple of cases where the nfsnode is not treated through the vnode that contains it, but it seems to me that that's where the bug is, and that explicit locks on the nfsnode would be rather a large amount of overhead to work around what is effectively a small set of vnode parameter pre-dereferences that shouldn't be occurring. One case is allocation, where the vnode container should be allocated and locked prior to manipulating the data pointer. Am I missing something? Has anyone asked Rick Macklem about this? > The > argument about FreeBSD vnode stacking/locking is simply meaningless if the > filesystem doesn't implement any node locking, so let's not confuse the > issue by bringing that up. IF the vnode lock implied an nfsnode (or inode) lock in all cases, and IF the nfsnode was never addressed, except through the vnode, and IF the vnode locking was done at a higher layer for all "bottom" FS's (where the vnode is not stacked on a vnode), and IF the requirement that the vnode be locked before a VOP call could be made against it was uniformly enforced, THEN I think there would be no NFS problems, nor a need for nfsnode locking above and beyond the vnode locking. This speaks directly to the call graph inversion (a pervasive problem in many places in the current VFS code, not just NFS), and in particular the inversion in the VOP_LOCK code, and, to a lesser extent, the non-management of vnodes by the FS's in which they represent objects. I also have to say that the *by far* most common problem I encounter in my frequently daily use of NFS (my home directory at work is NFS mounted) is lost UDP packets not getting retried or timed out. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810182048.NAA10205>