NFSv4 Linux features

feature	available in version	projected in version
basic file operations	2.6.4
locking	2.6.4
krb5	2.6.4
krb5i	2.6.6
krb5p	2.6.18
server reboot recovery (client)	2.6.4
server reboot recovery (server)	2.6.10-CITI_NFS4_ALL-1	2.6.13
POSIX ACLs (client)	2.6.4-CITI-NFS4_ALL-1	2.6.13
POSIX ACLs (server)	2.6.9-rc1
Full NFSv4 ACLs (client)	2.6.7-CITI_NFS4_ALL-1	2.6.13
Full NFSv4 ACLs (server)	?
delegations (client)	2.6.9-rc1
delegations (server)	2.6.10
named attributes (client)	?
named attributes (server)	?
security negotiation	?
automounting on fsid change	2.6.11-CITI_NFS4_ALL-1	?

Explanation of features:

basic file operations:

reading, writing, etc.

locking:

advisory byte-range locking using fcntl; in nfsv4 this is done by the nfsv4 protocol itself rather than a separate protocol.

krb5/krb5i/krb5p

Strong cryptographic security for NFSv2, v3, and v4, using Kerberos. There are three different (increasingly strong) levels of security:

krb5:

Authentication only: The header of each request and response is signed. You know who sent you this thing but you don't really know for sure what's in it.

krb5i:

Integrity: The header and body of each request and response is signed. So you know who sent this thing and what was in it.

krb5p:

Privacy: The header of each request is signed, and the body is encrypted, so you know everything you knew with krb5i, but everyone else knows less.

ACLs:

Linux supports ACLs based on the withdrawn POSIX ACL specification. NFSv4 provides much richer ACLs. On the client we allow the user to deal with either NFSv4 or POSIX ACLs, mapping between the two as necessary (and as possible). On the server we only allow a restricted set of NFSv4 ACLs that map to POSIX ACLs. Full server-side support for NFSv4 ACLs is also desireable, but presents some challenges; for example, it may not be possible to enforce NFSv4 ACLs when for local users on the server.

reboot recovery:

Client applications should be able to continue running after server reboots; system calls depending on rpc requests to the unresponsive server will hang, returning once the server comes back. Except for the delay, applications should see completely normal behavior.

delegations:

If only one client is accessing a file, then an NFSv4 server has the option of giving that client a delegation for the file, allowing the client to perform opens, closes, and locks locally. Should allow lower-latency opens, closes, and locks, and more aggressive client-side caching.

named attributes:

The NFSv4 protocol supports the association of files with arbitrary named attributes.

security negotiation:

Allow automatic negotiation of security flavor using SECINFO and the WRONGSEC error.

automounting on fsid change:

When the fsid changes (when we cross a mountpoint on the server), the client should automatically create a new mountpoint.