42nd IETF NFSv4 Strawman Slide 1 of 19 42nd IETF NFSv4 Strawman Spencer Shepler spencer.shepler@eng.sun.com draft-shepler-nfsv4-02.txt Spencer Shepler
42nd IETF NFSv4 Strawman Slide 2 of 19 Charter Goals for V4 • Improved access and good performance on the Internet • Strong security with negotiation built into the protocol • Good cross-platform interoperability • Designed for protocol extensions Spencer Shepler
42nd IETF NFSv4 Strawman Slide 3 of 19 Basic Design Approach • Recovery model the same as NFSv2/v3 • Single protocol to provide all NFSv4 functionality - MOUNT, NFS, NLM, ACL -> NFSv4 • One name space at server (not individually mountable) - Server is responsible for constructing file system structure • UTF-8 for all string encodings Spencer Shepler
42nd IETF NFSv4 Strawman Slide 4 of 19 RPC and Security • ONCRPC and XDR (RFC 1831 and RFC 1832) • UDP/TCP and use port 2049 • RPCSEC_GSS security flavor (RFC 2203) • GSS_API (RFC 2078) - authentication, integrity, privacy • Two security mechanisms - Private key (Kerberos V5) - Public key (SPKM [RFC 2025]) Spencer Shepler
42nd IETF NFSv4 Strawman Slide 5 of 19 Security Negotiation • Server may have multiple security mechanisms in use • Client and server will need to negotiate appropriate use • Minimal security used to initiate contact with server • If inappropriate mechanism, server will return error (NFS4ERR_WRONGSEC) • SECINFO procedure used by client to determine available security mechanism on a per file handle basis • SECINFO used when policy boundaries are crossed • SPNEGO (I-D draft-ietf-cat-snego-09.txt) is alternative Spencer Shepler
42nd IETF NFSv4 Strawman Slide 6 of 19 File Handles • Unique identifier of file system object at server • First file handle - MOUNT protocol separate and insecure - PUTROOTFH procedure to obtain first file handle • Persistent and Volatile file handles • Advantages of Volatile file handles - Flexibility and ease of general server implementation - Extended services at server easier to implement • Drawback of Volatile file handles - Implies client ability to recover from expired FH Spencer Shepler
42nd IETF NFSv4 Strawman Slide 7 of 19 File/directory attributes • NFS v2/v3 - Not all file systems support full range of POSIX attrs - No mechanism to add new attributes with protocol rev. - Attributes can not be obtained individually - Set of ‘supported’ attributes vary on type of FS object • NFSv4 - Extensible set of attributes with minor rev of protocol - Server can determine which attrs are supported - Client requests only attributes which are needed Spencer Shepler
42nd IETF NFSv4 Strawman Slide 8 of 19 File Attributes • type (REG, DIR, LINK, BLK, CHR, SOCK, FIFO) • mode (protection mode bits - traditional Unix) • accessbits (Read, Lookup, Modify, Extend, Delete, Execute) • UID (UTF8 string representing the user ownership) • GID (UTF8 string representing the group ownership) • size (uint64 size in bytes) • used (uint64 bytes of disk space allocation) • fileid (uint32 unique identifier for file within file system) • FSID (uint64 unique identifier of file system at server) Spencer Shepler
42nd IETF NFSv4 Strawman Slide 9 of 19 File Attributes Continued • atime (time when file data was last accessed) • mtime (time when file or directory was last modified) • ctime (time of last change of attributes of file or directory) • change (uint64 used by server to signify change to object) • time_delta (time granularity which server supports) • maxfilesize (uint64 max size of file on file system in bytes) • linkmax (max number of hard links for file) • name_max (max length of a file name component) Spencer Shepler
42nd IETF NFSv4 Strawman Slide 10 of 19 File Attributes Continued(2) • nlink (number of hard links to file or different names) • rtmax (max number of bytes for READ) • wtmax (max number of bytes for WRITE) • rdev (device description if type is CHR or BLK) • properties - LINK - SYMLINK - HOMOGENOUS - CANSETTIME - NOTRUNC - CHOWN_RESTRICTED - CASE_INSENSITIVE - CASE_PRESERVING Spencer Shepler
42nd IETF NFSv4 Strawman Slide 11 of 19 Compound Requests • Overcome latency issues through combination of requests • Simplify protocol and let client create complexity • File handles used to ‘link’ procedures • Evaluation stops on error • Example: - PUTROOTFH - LOOKUP - GETFH - READ - GETATTR Spencer Shepler
42nd IETF NFSv4 Strawman Slide 12 of 19 NFSv4 Procedures • NULL No operation • ACCESS Check access • COMMIT Commit data to stable storage • CREATE Create a file system object • GETATTR Get attributes • GETFH Get current file handle • LOCKR Create a read lock • LOCKW Create a write lock • LOCKT Test for lock • LOCKX Validate and extend lock Spencer Shepler
42nd IETF NFSv4 Strawman Slide 13 of 19 NFSv4 Procedures Continued • LOCKU Unlock file • LOOKUP Lookup file name • LOOKUPP Lookup parent directory • NVERIFY Verify attributes different • PUTFH Set current file handle • PUTROOTFH Set root file handle • READ Read from file • READDIR Read directory Spencer Shepler
42nd IETF NFSv4 Strawman Slide 14 of 19 NFSv4 Procedures Continued (2) • READLINK Read symbolic link • REMOVE Remove file system object • RENAME Rename directory • RESTOREFH Restore saved file handle • SAVEFH Save current file handle • SETATTR Set attributes • VERIFY Verify attributes same • WRITE Write to file • SECINFO Obtain available security Spencer Shepler
42nd IETF NFSv4 Strawman Slide 15 of 19 File Locking • Byte range locking • Lease based - 64bit lock id is presented by client - server returns lease id • Locked regions are protected from writes by other clients • Rejected lock requests are retransmitted by client • LOCKX procedures used to extend lease • LOCKX used to rebuild lock state in event of server failure Spencer Shepler
42nd IETF NFSv4 Strawman Slide 16 of 19 File Locking Issues • Lease renewal • Blocking locks • Denial of service • Lease scalability Spencer Shepler
42nd IETF NFSv4 Strawman Slide 17 of 19 Time representation struct nfstime4 { int64_t seconds; uint32_t nseconds; } • Seconds/nano-seconds from Midnight January 1, 1970 UTC • Time before January 1, 1970 is negative seconds • nseconds field is always added to seconds to represent time Spencer Shepler
42nd IETF NFSv4 Strawman Slide 18 of 19 Open issues • Two file locking proposals • Minor versioning • Server name space discovery and navigation • File attribute (required/optional) • Extended attributes • ACLs • Security mechanisms Spencer Shepler
42nd IETF NFSv4 Strawman Slide 19 of 19 Comments and Questions Spencer Shepler
Recommend
More recommend
