Date: Mon, 6 Oct 1997 00:43:09 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mark@quickweb.com (Mark Mayo) Cc: freebsd-current@FreeBSD.ORG Subject: Re: NFS changes since Rick Maclem... Message-ID: <199710060043.RAA29180@usr05.primenet.com> In-Reply-To: <19971003020238.59335@vinyl.quickweb.com> from "Mark Mayo" at Oct 3, 97 02:02:38 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi. I go to school at the University of Guelph, home of Rick Maclem > of BSD-Lite NFS fame. I was talking to Rick the other day and he said > that 99% of the NFS code in FreeBSD (and the other BSDs) was still > his - I questioned this since NFS seems to be always under a state > of minor change (at least since I've been using FreeBSD). > > So how far has the code deviated from Rick's code? I would have > imagined quite a bit in all this time, especially with NFS v3 now > being the default.. The deviations are structureal and functional, and are not terrifically significant. I would say Rick was right. The specific differences for the FreeBSD/NetBSD vs. the Lite2 code is that the size of the struct dirent is different from the "native" and "wire" formats on these systems. Specifically, there are field differences which were brought about by the USL suit, forcing CSRG to adopt the Heidemann code from UCLA to "route around the damage". The USL consent decree removed 6 files from 5 critical kernel subsystems, apparently in an attempt to make it difficult or impossible to produce a bootable BSD system which would potentially compete with USL's SVR4. So, there are: o The cookie changes (which differe between FreeBSD and all other BSD's). o The VM related changes (should be macro encapsulated so you can pick NetBSD or FreeBSD VM, but not significatly problematic). o Bug fixes that should have been done at a higher level (mosly because the NFS server is not considered to be a "VFS consumer", and therefore a peer with the local OS system calls, which, taken together, are also a "VFS consumer". The Lite/Lite2 integration was fairly slipshod, being an emergency measure to combat the 4.3 file "contamination" claims by USL. You can see the problems by looking at: o The path name buffer allocation and free interface, which is not reflexive o The namei interface, which is exponentially limited on symbolic link expansion becuase of buffer reuse o The VOP_ABORTOP being used to back out transactions in progress for operations which went further than they should have, such as created for existing files o The counting of the UFS VOP's instead of the decriptor structures in the array in vnode_if.c to setermine the number of VOPs (making it difficult to dynamically add an FS which adds to the total number of VOPs). o The existance of the struct fileops structure in the vnode, and its use for device node, pipe, and socket access instead of going through the VOP_ layer like all other vnode references (devfs fixes the device node part of this problem). o The existance of "cookies" in VOP_READDIR to allow NFS getdents() restart, instead of a seperation into a two call interface for "get block", "translate block to export format", which would have removed thee need for cookies brought on by the struct dirent size differences. o The lack of provision in the "call down" instead of "veto" architecture for advisory locking, making it near impossible to support NFS locking, and making 1:N fanouts (like union mounts) very difficult. o The use of per FS VOP_LOCK code. o The entire "vclean()" and related code for the vnode recycling, which destroys the locality of ihash, and in general causes lots of problems, incrementally. o The existance of per FS root mount code. o The existance of per FS NFS export code in the mount code. Etc.. FreeBSD has corrected others, which I won't bother listing here; mostly these corrections came from the need to load FS types as LKM's, and derives from the initial (1994) LKM code. > Anyways, there are a few of us here that are looking for something > to code, and if NFS is in need of repiar/enhancement it would be > a good project since the original NFS guru is at our finger tips. > If the code hasn't changed much, maybe I'll be able to convince > Rick to get off his ass and look at it again :-) And if it has > changed a bunch maybe this will scare him out of compacity... :-) I'm going to be in a better position to sit down at a whiteboard with the necessary people "Real Soon Now". For the NFS code, I'd say it is currently bruised; the changes that have been made are mostly "damage control" (not all of them). I would hesitate to step on Doug Rabson's toes in this area, since he's being the guy bandaging the bruises. However, I think the NFS code may need to be completely reworked in light of getting the expedient code hacks out of there, and replaced with "correct" code that both fits the standards model, the principles of functional abstraction, and the intent of the Heidemeann framework. Mostly, this will impact the server code more than the client code. Like I said, I'll be in a better position soon, but I'm not there yet; I'd like to not stir the pot before that point. David Greenman, and the other architectural "mentors" of the FreeBSD code *really* need to be invloved in decisions on anything as fundamental as this, so that the concerns of the rest of the kernel can be adequately represented. It's too easy to damage other things at this level if you focus only on the immediate problem (e.g.: NFS) to the exclusion of all other possible considerations. Well. That was a diatribe... I didn't mean to go on so long. ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710060043.RAA29180>