The State of NFSv4. Spencer Shepler Sun Microsystems 6 August 2001

Transcription

1 The State of NFSv4 Spencer Shepler Sun Microsystems 6 August 2001

2 State of NFSv4 Review of current state model Raise issue with Posix clients and current state model Propose solution

3 Where does the State begin? Hierarchy of NFSv4 state begins with association between a single client and server This hiearchy is important because the LEASE period and recovery are directly tied to it NFSv4 supports many definitions of client A CLIENTID is shorthand for a client definition

4 CLIENTID may represent these entities at the NFS client Traditional Unix NFS Client (M-Processes / N-Threads) (Y-Users/Principals) User Level Client (1-Processes / N-Threads) Individual Thread

5 Creation of CLIENTID With SETCLIENTID, client chooses an opaque identifier and a verifier Server assigns a CLIENTID Client confirms use with SETCLIENTID_CONFIRM Server uses RPC authentication to verify request (saves principal for future reference)

6 CLIENTID creation (Client) SETCLIENTID SETCLIENTID <identifier> <verifier> <CLIENTID> <verifier> (Server) Identifier used before? If so, verifier different? If so, mark for state release On retransmit, return previous response SETCLIENTID_CONFIRM SETCLIENTID_CONFIRM <verifier> On confirm request, release all previous client state On retransmit, do nothing and return previous response

7 What do we have? (Client) (Server) CLIENTID Lease

8 Lockowner Next level of state associates client's entity of file locking with the protocol's operations For Posix clients, this is the process id* Other clients will choose the appropriate association for lockowner OPEN operation is where the lockowner is introduced to the server Use of lockowner / sequence-id pair is

9 Lockowner association (Client) OPEN OPEN <CLIENTID> <lockowner> <sequence-id> <stateid> <verifier> (Server) First time lockowner used? Request confirm On retransmit, return previous response OPEN_CONFIRM OPEN_CONFIRM <verifier> <sequence-id+1> <stateid'> On confirm, change stateid to reflect change in shared state On retransmit, do nothing and return previous response

10 What do we have? (Client) (Server) CLIENTID Lease Lockowner Lockowner Lockowner

11 Stateid Server generates it Unique for entire server Stateid incorporates Shorthand reference to lockowner Shared file locking/open state between client/server Marker to detect server reboot Stateid changes at each of the following operations: LOCK, LOCKU, CLOSE, OPEN_CONFIRM, OPEN_DOWNGRADE

12 Sequence-id Initiated by client Associated with lockowner Allows client to order requests (OPEN)

13 Stateid changes (Client) <STATE_OP> <stateid> <sequence-id> <stateid ' > (Server) Stateid (previous server)? Valid stateid? Valid sequence id? <STATE_OP> <STATE_OP> <stateid ' > <sequence-id + 1> <stateid '' > Stateid (previous server)? Valid stateid? Valid sequence id? On retransmit, return previous response

14 What do we have? (Client) (Server) CLIENTID Lease Lockowner Lockowner Lockowner Stateid Stateid' Stateid'' Stateid'''... Stateid+n

15 Delegation Servers allows the client to manage state Delegation is done per-file Call-back path must be present A delegation-stateid is used as shorthand reference If delegation provided, client manages state for all of its lockowners

16 What do we have? (Client) (Server) Lockowner Delegated file CLIENTID Lockowner Lease Lockowner Stateid Stateid' Stateid'' Stateid'''... Stateid+n

17 What's Broken? Association of lockowner is made at OPEN Doesn't allow for POSIX fork()/file locking Child isn't guaranteed OPEN will succeed

18 Posix fork(), shared file table entries, and file locking Proc A Proc A' Conflict for file lockng File-A Lockowner (pid)

19 One Solution Add level of indirection Introduce openowner that can represent multiple processes at a Posix/Unix client OPEN changes to accept openowner and return openstateid LOCK_CONFIRM added to introduce lockowner at the time of file locking For clients that don't need this, they will have one lockowner per openowner

20 Posix fork(), shared file table entries, and file locking Proc A Proc A' File-A Openowner (per client?) Lockowner (pid) Lockowner (pid)

21 Openowner / Lockowner association (Client) OPEN <CLIENTID> <openowner> <open-seq-id> <openstateid> <verifier> (Server) First time openowner used? Request confirm OPEN_CONFIRM <verifier> <open-seq-id+1> <openstateid'> <openowner> LOCK <lockowner> <lock-seq-id> <lockstateid'>

22 Now what do we have? (Client) (Server) Openowner CLIENTID Openowner Lease Openowner Lockowner Lockowner Lockowner Stateid Stateid' Stateid... Stateid' Stateid+n... Stateid+n

23 Simultaneous OPENs Lack of a serialization point at the client Simultaneous OPENs can occur for the same target file Hard linked file that is referenced under two or more names as an example Provide access to the embedded sequence-id which is contained in the stateid Allow the client to choose which

24 "open" stateids openstateid { uint64_t sequenceid; opaque ident<>; };

25 Openowner / Lockowner association (Client) OPEN("foo") <CLIENTID> <openowner> <open-seq-id> (Server) "foo" == "bar" OPEN("bar") <CLIENTID> <openowner> <open-seq-id+1> <openstateid> Client stores openstateid for later use Client notes that openstateid is "older" for this response and does not save <openstateid+1'>

26 Remaining Issues Confirm use of sequence id for OPEN / LOCK Detail rules of when openstateid or lockstateid should be used Unknown...

27 ??? Questions