NFSv4 Strawman Spencer Shepler spencer.shepler@eng.sun.com - - PowerPoint PPT Presentation

42nd IETF NFSv4 Strawman Slide 1 of 19 Spencer Shepler

42nd IETF

NFSv4 Strawman

Spencer Shepler spencer.shepler@eng.sun.com draft-shepler-nfsv4-02.txt

42nd IETF NFSv4 Strawman Slide 2 of 19 Spencer Shepler

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

42nd IETF NFSv4 Strawman Slide 3 of 19 Spencer Shepler

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

42nd IETF NFSv4 Strawman Slide 4 of 19 Spencer Shepler

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])

42nd IETF NFSv4 Strawman Slide 5 of 19 Spencer Shepler

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

42nd IETF NFSv4 Strawman Slide 6 of 19 Spencer Shepler

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

42nd IETF NFSv4 Strawman Slide 7 of 19 Spencer Shepler

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

42nd IETF NFSv4 Strawman Slide 8 of 19 Spencer Shepler

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)

42nd IETF NFSv4 Strawman Slide 9 of 19 Spencer Shepler

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)

42nd IETF NFSv4 Strawman Slide 10 of 19 Spencer Shepler

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

42nd IETF NFSv4 Strawman Slide 11 of 19 Spencer Shepler

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

42nd IETF NFSv4 Strawman Slide 12 of 19 Spencer Shepler

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

42nd IETF NFSv4 Strawman Slide 13 of 19 Spencer Shepler

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

42nd IETF NFSv4 Strawman Slide 14 of 19 Spencer Shepler

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

42nd IETF NFSv4 Strawman Slide 15 of 19 Spencer Shepler

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

42nd IETF NFSv4 Strawman Slide 16 of 19 Spencer Shepler

File Locking Issues

• Lease renewal
• Blocking locks
• Denial of service
• Lease scalability

42nd IETF NFSv4 Strawman Slide 17 of 19 Spencer Shepler

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

42nd IETF NFSv4 Strawman Slide 18 of 19 Spencer Shepler

Open issues

• Two file locking proposals
• Minor versioning
• Server name space discovery and navigation
• File attribute (required/optional)
• Extended attributes
• ACLs
• Security mechanisms

42nd IETF NFSv4 Strawman Slide 19 of 19 Spencer Shepler

Comments and Questions