Date: Sun, 15 Mar 2009 13:22:16 -0700 From: Tim Kientzle <kientzle@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-arch@freebsd.org Subject: Re: NFS version 4.0 for FreeBSD-CURRENT Message-ID: <49BD6378.9030501@freebsd.org> In-Reply-To: <Pine.GSO.4.63.0903151520590.16993@muncher.cs.uoguelph.ca> References: <Pine.GSO.4.63.0903151520590.16993@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Ah, yes. I remember reading the NQNFS paper some years ago. Nice work! Q: Does this support NFSv4 ACLs? As I recall, trasz@ has NFSv4 patches in P4 that have yet to be merged; I've been waiting on that to work on NFSv4 support for tar/cpio. Q: How does this relate to the new NFS lockd recently committed? (by Doug Rabson? I can't remember now.) As for schedule, that depends. There was talk about branching 8.0 in April. If that's still the plan, then it might be best to just wait. But the website still announces August. If that's the plan, I'd be happy to push this in now with a build option to select which implementation to use. Have that default to the new implementation now in -CURRENT, but leave the option to ship 8.0 with the old implementation as the default. That would give a fair bit of production exposure during the 8.x cycle (some people will enable the new code, especially by 8.1 when the new code should have stabilized some). Then switch the default to the new code for 9.0. As for naming, I see no problems calling it (lowercase) nfs4 even if it does support (uppercase) NFSv2 and NFSv3. Tim Rick Macklem wrote: > As some of you might already know, I have been working on an > implementation of NFSv4.0 for BSD for some time now. My original > interest in NFSv4.0 came about because I felt that a component > of it called delegations might permit significant performance > improvements along the lines of what I had hoped to achieve with > an experimental protocol I called Not Quite NFS long long ago. > > To experiment with the use of delegations, I needed an implementation > and I got to work on that around Fall 2001/Winter 2002. (If I had > had any idea how long it was going to take to get to a near production > quality implementation, I would have never started, but I'm finally > there.:-) > > There has been some indication of interest in incorporating this > into FreeBSD-CURRENT/8 and I am posting here to start a discussion > of this. > > I feel (and Robert Watson seems to agree) that replacing the current > NFS implementation would be impractical for at least one release > cycle. It does include NFSv2 and 3 support in it, but it would take > some time to gain experience with the implementation and incorporate > all the features in the current release into it. As such, it seems > appropriate to have it live side-by-side with the current implementation. > > Here's a brief overview of the current code base: > - approximately 75,000 lines of C in the following subdirs > nfscl - generic client code that can be shared by the ports. > (This includes doing the RPCs using code that avoids most of my > infamous macros and handling functions for the NFSv4 state.) > nfsclient - a copy of sys/nfsclient tweaked so that it calls functions > in nfscl instead of doing the v2,3 RPCs. (As such, it retains the > caching semantics, etc of the current client.) > nfs - functions shared by the client and server > nfsd - the server code > nfscrypto - a couple of small functions for helping with RPCSEC_GSS > (these aren't required for Doug Rabson's new RPC code) > > Current work: > I am currently in the process of converting it to use Doug Rabson's new > RPC layer and re-organizing things so that the two servers can co-reside > in the kernel (the client already does co-reside). This work should be > completed in a few weeks. Beyond that, the only NFSv4.0 feature I might > be looking at that isn't yet implemented is referrals. > > Code stability: > The server code ran here in two FreeBSD NFS servers for a couple of years > without difficulties. The client has been tested fairly extensively for > the Mac OS X port (25 iMacs in a lab here + about 350 downloads by > others). At this point I suspect bugs will be mostly related to > architectures other than i386 and, maybe, issues running on fast, > heavily SMP machines. (The code is SMP safe, to the best of my > knowledge.) > > What to call it? > I currently call it newnfs with options NFSCL and NFSD, but I could > care less what it is called. Calling it nfsv4 seemed inaccurate, since > it does have nfsv2 and v3 support in it. > > So, what do folks think? rick > ps: I haven't even looked at NFSv4.1 implementation yet. > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49BD6378.9030501>