Date: Sun, 1 Mar 1998 23:04:40 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: karl@mcs.net (Karl Denninger) Cc: tlambert@primenet.com, jb@cimlogic.com.au, joe@via.net, hackers@FreeBSD.ORG Subject: Re: help - make world fails Message-ID: <199803012304.QAA28537@usr08.primenet.com> In-Reply-To: <19980301094530.23053@mcs.net> from "Karl Denninger" at Mar 1, 98 09:45:30 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I've seen enough commentary on the hackers and current lists to think that
> > > perhaps its not a good idea to consider -current a stable piece of code
> > > right now..... am I right in this? In particular, the place I usually run
> > > into trouble is the NFS code and its stability.
> >
> > Please clarify here. You mean NFS *client*, right? I've been getting
> > pretty deeply into this code lately, and it's the *client* that freezes
> > up here...
>
> So you're saying the NFS *SERVER* Code is completely stable right now? :-)
>
> (Actually, both are germane to me).
The NFS *SERVER* code is a client of VFS, just as the system calls
are a client of VFS. It proxies the VFS interface out via RPC calls
to client machines. In effect:
===========================================================================
Client machine Server machine
u
------------------------------------------------------------------
k
--------------------- ---------------------
| | ,--------> | RPC server |
| system calls | | ---------------------
| | | | NFS server code |
--------------------- | ---------------------
| VFS | | | VFS | (peering)
--------------------- | ---------------------
| NFS client code | | | local media FS |
--------------------- | ---------------------
| RPC client | <------'
---------------------
===========================================================================
If being a client of the VFS didn't work, then your system calls
would not work. 8-).
There is a slight problem in that "some pigs are more equal than
others" -- in other words, the NFS server is an unequal pig when
compared to system calls. System calls are given precedence in
any conflict between the two.
The biggest place you can see this is the "cookie" code that is
used for arbitratry directory iteration restarts, used in
VOP_READDIR by NFS, but not by other VFS clients.
This results from differences in the struct dirent exported by FFS
and the struct dirent exported by NFS.
Doug Rabson and I agreed a long time ago that the best soloution
to this would be to seperate the VOP_READDIR into two VOPS: one
to get the directory blocks, and one to iterate within them.
This would get rid of the cookies at the interface level, and
the server would get block snapshots that it could get lease
notifications on. A worst case scenario here is a create after
delete in the same directory block, with uncompacted free space.
This would result, potentially, returning a file name to the
client twice, if the name was 24 characters or larger.
AFAIK, there is one bug, related to AIX clients, in the NFS cookie
restart code.
There may be other bugs, but they will all be in the (very thin)
veneer. Mostly in the complex parts of the name lookup code,
where NFS, as a VFS client, is forced to jump through hoops for
the underlying code's bias toward system call consumers. One
very good example of this problem is that a VFS consumer must be
prepared for the underlying VFS code to free its resources without
warning or notification (like cn_pnbuf, for instance 8-)).
For the most part, I believe the server code, at least for V2, is
pretty solid, and I was pretty sure about V3 as well, but there is
a wierdness in the multiple directory entry lookup; I don't know
if it will ever be triggered, but there is a potential for a buffer
overrrun.
Does that (sort of) answer your question?
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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803012304.QAA28537>