Server state
From Linux NFS
(Difference between revisions)
(→basic file operations:) |
(→Explanation of features:) |
||
| Line 95: | Line 95: | ||
*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. | *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. | *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: | + | * named attributes: The NFSv4 protocol supports the association of files with arbitrary 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. |
| - | security negotiation: | + | * automounting on fsid change: When the fsid changes (when we cross a mountpoint on the server), the client should automatically create a new mountpoint. |
| - | 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. | + | |
*Replication: creation of a NFSv4 mirror server that can be used by clients as the original server. | *Replication: creation of a NFSv4 mirror server that can be used by clients as the original server. | ||
*Migration : When a server has been replicated, a client can be migrated to use the replicated server transparently. | *Migration : When a server has been replicated, a client can be migrated to use the replicated server transparently. | ||
Revision as of 09:35, 14 April 2006
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.7 | |
| krb5p | 2.6.7 | |
| server reboot recovery (client) | 2.6.4 | |
| server reboot recovery (server) | 2.6.13 | |
| POSIX ACLs (client) | 2.6.14 | |
| POSIX ACLs (server) | 2.6.14 | |
| Full NFSv4 ACLs (client) | 2.6.14 | |
| Full NFSv4 ACLs (server) | 2.6.14 | |
| delegations (client) | 2.6.10 | |
| delegations (server) | 2.6.10 | |
| named attributes (client) | 2.6.18 | |
| named attributes (server) | 2.6.18 | |
| security negotiation | 2.6.16 | |
| automounting on fsid change | 2.6.12 | |
| Replication | 2.6.19 ? | |
| Migration | 2.6.19 ? |
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.
- Replication: creation of a NFSv4 mirror server that can be used by clients as the original server.
- Migration : When a server has been replicated, a client can be migrated to use the replicated server transparently.
