Subject: NFS version 4 at the University of Michigan

From: "Kendrick M. Smith" <[email-masked]>
Date: Fri, 8 Feb 2002 05:21:34 -0500 (EST)

This is an announcement of the first public release of NFS version 4
for Linux, by the University of Michigan.  Up to this point, all of
our work has been done privately, but we are now hoping to involve
the open-source community at large.  Eventually, we hope to integrate
our NFS version 4 implementation into the Linux kernel proper, and
find a long-term maintainter for NFS version 4 (possibly one of the
current NFS maintainers, possibly one of us working in their spare
time).

To download a patch for the 2.4.4 kernel, please see:
http://www.citi.umich.edu/projects/nfsv4/feb_2002_rel/mainpatch.html

At this point, only the 2.4.4 kernel is supported.  (This is the kernel
we have been using for development).  A port to the 2.5.x series is in
the works, but we decided to go ahead and release the 2.4.4 patch now,
rather than delay the release to do the port.

Note!  At this point, the client should be fairly stable and ready for
tearing apart by the open-source community.  The server, on the other
hand, is another story.  If you do look at the server, please be
forewarned that it is not really ready for public consumption: it still
needs systematic auditing and cleanup.

We are hoping that this release will result in:

o More pairs of eyeballs to study the client code,
  find bugs, simplifications, etc.  If you audit a
  section of code but don't find any problems,
  please let us know anyway!

o Code contributions for anything on the client side
  at all.  I have tried to flag down well-defined
  projects with the label "TODO"; just grep through
  the source code to get an idea of what needs to be
  done.  If you do want to work on something, it is
  probably a good idea to write one of us beforehand,
  to make sure that no-one else is also working on it!

In addition to the TODO's, there are also a few totally
unimplemented protocol features which could be worked on:

  - support for extended (named) attributes, using Andreas
    Grunbacher's ea/acl patch as a starting point.  This is
    a very large project, since mapping between the Linux
    internal interfaces and the on-the-wire protocol is
    highly nontrivial.

  - support for ACL's.  One of our students has already done
    some work on this, but we have not integrated it into the
    patch yet.  Once it is integrated, there is still a
    little more work remaining here.

  - filesystem replication and migration.  This is another
    very large project which we haven't even had the chance
    to start.

  - recovery from server-side reboots.  I am working on this at
    the moment and hope to finish by early March, but if someone
    wants to help out, there is probably room for another
    contributor here.

o Testing, testing, testing.  It is impossible for a lab of our
  size to subject our implementation to nearly the level of testing
  that the open-source community can provide.  We can pass the
  standard Connectathon tests, but not much else is known.  The
  'fsx' tests are known to fail because we are still working in
  the 2.4.4 kernel and have not merged the fsx-related fixes which
  appeard in later kernels.  If anyone is willing to devise some
  more rigorous tests, it would help the project enormously!

o Discussions with the Linux community which will lead toward the
  eventual inclusion of NFS version 4 into the kernel proper.  One
  issue which must be addressed is integration with NFS v2/v3.  At
  the present time, we are using a codebase which is completely
  independent of NFS v2/v3.  This turned out to be more convenient
  for development, but for long-term maintainability, integration
  with earlier versions of NFS is the only thing which makes sense.
  Another issue is that the NFSv4 protocol seems to require minor
  changes to existing VFS interfaces; we hope to hash out the details
  with the kernel maintainers during the 2.5.x cycle.

The following people have contributed to our project:
  Kendrick Smith   <[email-masked]>
  Andy Adamson     <[email-masked]>
  Jim Rees         <[email-masked]>
  Dug Song         <[email-masked]>
  Eric Kustarze    (now at Sun Microsystems)
  Jake Moilanen    (now at IBM)
  Chris Myers      <[email-masked]>

The mailing list
  [email-masked]
can be used to send mail to all of the NFSv4 developers at the University
of Michigan.

Funding has been generously provided by Sun Microsystems and Network
Appliance.

Disclaimer: This is development code which is incomplete in many ways,
and is not nearly to the point of being ready for the kernel.  Please
bear this in mind when playing with it, and have fun tearing apart our
code!

Cheers,
 Kendrick Smith
 Center for Information Technology and Integration, University of Michigan

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 11 Feb 2002 04:10:20 -0600

On Sat, Pavel Machek wrote:
> Hi!
> Could you sumarise advantages of NFSv4 over v3? Is there usermode
> server for NFSv4? What servers for v4 are known working?

The highlights are:
- NFSv4 allows *nix and windows clients to play well with each other
  (NFSv4/CIFS clients can interact appropriately).
- Strong security (authentication/integrity/privacy) is required of
  implementations.
- A single protocol instead of a collection of protocols (e.g. file
  locking, ACL support are in the protocol)
- Delegation (similar to CIFS oplock support) allows for more
  aggressive caching at the client

The University of Michigan/CITI work is the first to "release" but the
other implementations are not far behind.  We will be meeting at
Connectathon in a couple of weeks to do interoperability testing.
Should be a good event.

-- 
Spencer

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 11 Feb 2002 10:25:12 -0500

On Sat, Pavel Machek wrote:
% Could you sumarise advantages of NFSv4 over v3?

Other folks forgot my personal favourite:
	NFSv4 is lot more complex to deploy and manage than NFSv3.

Ran

---

From: Brian Pawlowski <[email-masked]>
Date: Mon, 11 Feb 2002 16:13:32 -0800 (PST)

> 	NFSv4 is lot more complex to deploy and manage than NFSv3.

(Following on to Dave's comments...)

That said, NFS Version 3 did not eliminate NFS Version 2.

The most complex thing to manage and deploy in NFS Version 4 is
probably the security (Kerberos)?  While mandatory to implement,
it is certainly optional to deploy.

On complex state within the protocol - delegations, open/close
in support of new locking semantics? - this should be transparent.
The complexity is in the protocol - not in the administration.
Hopefully a user would see more reliable locking if anything.

Client to server negotiation has always occurred transparently
attempting to bind to highest capabilities.  Client mount options
exist to override default bindings (and some server implementations
allow global disable of features to affect all clients).  Version 3
deployment was not without its bumps.  Such implementation features
(allowing choice) are certainly expected to persist in the NFS Version 4
world.

beepy