File Locking in NFS. File Locking: Share Reservations

Transcription

1 File Locking in NFS NFSV4 operations related to file locking NFS supports file locking Applications can use locks to ensure consistency Locking was not part of NFS until version 3 NFS v4 supports locking as part of the protocol (see above table) 17 File Locking: Share Reservations The result of an open operation with share reservations in NFS. a) When the client requests shared access given the current denial state. b) When the client requests a denial state given the current file access state. 18 1

2 Client Caching In NFSv3, client side caching is left to the implementation Different implementation use different caching policies Sun: allow cache data to be stale for up to 30 seconds In NSFv4, client checks cache validity when the file is opened. Modified data is written to the server when the file is closed. Client side caching in NFS. 19 Client Caching: Delegation NFSv4 supports delegation Read delegations can be granted to multiple clients at the same time A write delegation can be granted to only one client. Server uses a callback mechanism to recall the delegation. 20 2

3 RPC Failures Three situations for handling retransmissions: use a duplicate request cache: a) The request is still in progress b) The reply has just been returned c) The reply has been returned some time ago, but was lost. 21 Security Simple authentication in NSFv3: client passes its user ID and group ID to the server along with a list of groups it claims to be a member of. The NFS security architecture 22 3

4 Security in NFSv4 NFSv4 supports RPCSEC_GSS, a general security framework that has plugins for multiple security mechanisms RPCSEC_GSS supports message integrity, confidentiality, and authentication. The primary authentication method is Kerberos v5, and an alternative ti is LIPKEY, a public key system Access control is done with ACLs 23 Security in NSFv4 Secure RPC in NFSv4 24 4

5 Replica Servers NFSv4 supports replication Replicationis is only usedfor read only volumes 1 The client mount a filesystem on the client, and obtains the replica locations. 2 The server is no more reachable by the client. 3 The client mount a replicated filesystem. 25 Coda File System Developed at CMU in the early 1990s Designed for mobile computing scenarios Allow a client to continue operation even if access to the file servers is (temporarily) impossible 26 5

6 Naming in Coda Shared files have the same name as seen from all clients (different from NFS) 27 Naming in Coda Files are grouped into volumes A volume corresponds to a partial subtree in the shared name space maintained by the servers Usually a collection of files associated with a user Volumes can be replicated, a logical volume represents a possibly replicated physical volume Each logical volume has a Replicated Volume Identifier (RVID), and eachphysical volume has its own Volume Identifier (VID) Each file has a 96 bit file identifier: 32 bit RVID + 64 bit unique file ID 28 6

7 Naming in Coda Implementation and resolution of a Coda file identifier 29 Sharing Files in Coda Transactional behavior for sharing files: similar to share reservations in NFS File open: transfer entire file to client machine [similar [i il to delegation] Use session semantics: each session is like a transaction Updates are sent back to the server only when the file is closed The transactional behavior in sharing files in Coda. 30 7

8 Client Caching Cache coherence is maintained by means of callbacks The server keeps a callback promise for each client that has a local copy of a file When a client changes its local copy, it notifies the server, and the server sends an invalidation message or callback break to the other clients As long as a client knows it has a callback promise for a file, it can safely use its local copy The use of local copies when opening a session in Coda. 31 Server Replication Use replicated write protocol: read one, write all Writes are sent to all members in AVSG (all accessible replicas) How to handle network partitions? Use optimistic strategy: allow conflicting operations on replicas across network partitions Reconcile upon reconnection: detect conflicts using a Coda version vector Example: [2,2,1] and [1,1,2] is a conflict => manual reconciliation Two clients with a different AVSG for the same replicated file. 32 8

9 Disconnected Operation The state transition diagram of a Coda client with respect to a volume. Use hoarding to provide file access during disconnection Prefetch all files that may be accessed and cache locally If the client becomes disconnected, it enters the EMULATION state, where all file requests are serviced locally When the client reconnects, it enters the REINTEGRATION state, where conflicts are detected and resolved 33 9