NFS version 4.0 for FreeBSD-CURRENT

[Robert Watson]

On Thu, 19 Mar 2009, Zachary Loafman wrote:

> First off, I wanted to start by saying something that may interest the 
> community at large: We (Isilon) recently staffed a small NFS group. Our 
> intention is to use and extend Rick's awesome effort. We will have three 
> full-time employees working on producitizing it for us "soon" - by mid-May 
> all three employees should be working on v4. It is our intention to give the 
> work back, but we're still trying to work out our branching/upstreaming 
> model.
>
> I don't know if that affects the timing on this being merged to CURRENT or 
> not. It might be nice if we had an opportunity to review some things prior 
> to APIs/VOPs being set in stone, but it would also be nice to get wider 
> exposure for Rick's code.

If we adopt Rick's code as a "second" experimental stack, and use the existing 
stack as the default, then I think we can reasonably claim that the binary 
interfaces specific to it can be changed, especially if we do a good job of 
tagging which interfaces those are.  I have proposed Rick for a commit bit 
with the hopes of getting the NFS code in the tree sooner rather than later so 
that it can get exposure, etc, however.  BTW, this news from Isilon sounds 
excellent, and is something that the community as a whole will appreciate a 
great deal.

Something I would like to see happen in the quite short term is get more hands 
looking at Edward's NFSv4 ACL implementation.  Rick's code supports it, but 
since the NFSv4 ACL code requires rolling our ACL ABI, writes things to disk, 
etc, I think it's actually much more sensitive to binary compatibility 
concerns.  I'd like to get as many hands as possible doing a review of the 
semantics (especially UFS, POSIX.1e, Solaris/ZFS, NFSv4, Samba, smbfs, Mac OS 
X, etc compatability concerns) in the next month or so as possible.  Having 
done the POSIX.1e ACL support almost ten years ago now, I can say that you get 
stuck with a lot of things you regret if you're not careful, and that the most 
important concern is semantic interoperability with other systems.

The plan right now is to have a semi-formal NFSv4 on FreeBSD session 
(mini-summit) at the developer summit, FYI, with a goal of working out a 
number of things relating to NFSv4, the future of NFS on FreeBSD, and the 8.x 
release.  Among other things, I hope we can come out with a clear set of 
"stuff that needs to be done", maybe even a "who's doing it".

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> On Sun, Mar 15, 2009 at 05:20:20PM -0400, Rick Macklem wrote:
>> On Sun, 15 Mar 2009, Alfred Perlstein wrote:
>>>
>>> I think it wise to look at 4.1 and scoping that out before taking
>>> the time to integrate this to gain an understanding of:
>> NFSv4.1 is still way out there. It hasn't reached RFC stage yet and
>> vendors are only testing bits and pieces of it. (The current draft
>> of the "minor" revision is over 500 pages.)
>>
>> All the code vendors are currently shipping is running 4.0.
>
> I think v4.1 is closer than you might think. We've received numerous
> requests for pNFS, and I think many vendors will ship basic 4.1 stacks
> this year.
>
>>> 1) what it would take to get to 4.1?
>> A lot. A required feature is something for handling RPC transport
>> called sessions. One guy has been looking at doing sessions for
>> FreeBSD (hopefully integrated with Doug Rabson's new RPC code),
>> but I have no idea if he has made any progress.
>
> Can you put us in contact? I'd like to avoid duplication of effort here.
>
>>> 2) how we would interoperate with other machines until we
>>> get 4.1 (is everyone doing 4.0 or 4.1?).  When will 4.1 become
>>> the defacto standard (is it already?)?
>> Systems should still support 4.0 for a long time. I have no idea
>> when 4.1 will become a defacto standard, but I'd guess years.
>
> We've idly been considering going 4.1-only given the relatively slow
> adoption of 4.0. 4.1 has created a fair amount of buzz and may raise
> adoption of 4.x. I can't really say for sure. Nor can I say for sure
> what we'd eventually settle on, since the relative cost of 4.0 once you
> have 4.1 is fairly small.
>
>> I've tried reading the drafts and got swamped. Honestly, I think a
>> 4.1 implementation would take man years of effort and is beyond
>> what I am capable of.
>
> I hope we can help. :)
>
> -- 
> Zach Loafman | Staff Engineer | Isilon Systems
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>