Projects: NFS Version 4 Linux features
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.
- advisory byte-range locking using fcntl; in nfsv4 this is done by the nfsv4
protocol itself rather than a separate protocol.
- Strong cryptographic security for NFSv2, v3, and v4, using Kerberos.
There are three different (increasingly strong) levels of security:
- 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.
- Integrity: The header and body of each request
and response is signed. So you know who sent this thing and what
was in it.
- 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.
- 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.
- 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
- security negotiation:
- Allow automatic negotiation of security flavor using SECINFO and the
- automounting on fsid change:
- When the fsid changes (when we cross a mountpoint on the server), the
client should automatically create a new mountpoint.