NFS4: Now we're really moving
Martin Pool
VA Linux Systems
What is NFS?
- de-facto standard for file sharing on Unix/Linux/...
- main competitor is Microsoft CIFS/SMB
- remote filesystems appear as local
- NFS4 standard released Jan 2001
Earlier Problems:
- "NFS server not responding"
- Not very secure
- Needs centralized control to work well
- Ho-hum Linux support
- Hard to perform well on stock hardware
Why use NFS at all?
- Local disks are cheap and large
- Reputation for insecurity
- Files can be published/updated over the web
Arguments for a network filesystem:
- Simplify administration
- Buy storage appliances, rather than dumb disks
- HTTP is a very restricted protocol
- The network looks very different to the local disk
Ideas from NFS3:
- Built on async remote procedures
- As transparent as possible, but no more so
- Relatively small implementation
- Minimum disruption from client or server crashes
Improvments from NFS3:
- Run over TCP by default
- Just one connection on predictable port,
integrating locking and mounting
- Many throughput and latency improvments
- Doesn't mandate a Unix server
Ideas from SMB:
- Chained commands to reduce latency
- Support for MS semantics (SHARE modes,
ACLs, RENAME...)
- Unicode support (but done right!)
- OpLocks (aka Delegations)
Ideas NOT taken from SMB:
- Closed, proprietary protocol
- 39(!) byte header, complex and inconsistent formats
- Negotiated (aka complex) protocol encodings
- Kludges for back-compatibility
Security
- Negotiated RPC security: every request
signed/encrypted
- Connection-level security: run over SSH, IPsec, ...
- Single predictable connection makes firewalling
simpler
- Access control lists
- Users identified by name, not uid
Latency
- The other barrier over the Internet
- Batch up operations into compounds
- Let TCP handle flow control
- Delegations
- Writes need not be synchronous
Delegations
- Often, one client uses a file intensively
- Client can gain a delegation of that file
- Most operations then done on client
- Write back to server on request
Caching
- Client may locally cache files to disk
- Could even have proxy caches!
- Disconnected operation not supported yet
Availability/scalability
- Server can ask clients to migrate
- Filesystem replicas
- Orderly recall of delegations
File Attributes
- Available attributes may vary (e.g.
ctime, symlinks, archive bit)
- Bag of standard attributes
- Plus arbitrary named attributes
Challenges for Linux:
- Stable and fast implementations
- ACLs? Extended attributes?
- Support for non-volatile cache memory
- More scalable file systems
Open Implementations
- CITI.umich.edu: kernel client and server
- n4.samba.org: userspace client and server
Produced by
PinPoint
at
Mon Jun 18 07:14:40 2001UTC