Synchronization in Distributed File Systems Advanced Operating System Zhuoli Lin Professor Zhang

Outline – Semantics of File Sharing – File Locking – Sharing File in Coda – Future Work

Semantics of File Sharing When two or more users share the same file at the same time, it is necessary to define the semantics of reading and writing precisely to avoid problems. Single – processor systems Distributed system

Semantics of File Sharing In a single – processor system, it permits processes to share files. When a read follows a write, the value returned by the read is the value just written.

Semantics of File Sharing In a distributed system, if a client locally modifies a cached file and shortly thereafter another client reads the file from the server, the second client will get an obsolete file.

Semantics of File Sharing Four approaches to deal with shared files in a distributed system.

Semantics of File Sharing UNIX semantics – UNIX semantics can be achieved easily as long as there is only one file server and client do not cache files. – All reads and writes go directly to the file server, which processes them strictly sequentially.

Semantics of File Sharing Session semantics – Instead of requiring a read to see the effects of all previous writes, one can have a new rule: Changes to an open file are initially visible only to the process that modified the file. Only when the file is closed are the changes made visible to other processes. – Most distributed file systems implement session semantics.

Semantics of File Sharing Immutable files – To create an entirely new file and enter it into the directory system under the name of a previous existing file, which now becomes inaccessible. – Files cannot be updated, but directories can be. – The only operations on files are create and read, no way to open and write.

Semantics of File Sharing Transactions – To access a file or a group of files, a process first executes some type of BEGIN_TRANSACTION primitive to signal that what follows must be executed indivisibly. – When the requested work has been completed, an END_TRANSACTION primitive is executed. – The system guarantees that all the calls contained within the transaction will be carried out in order. – If two or more transactions start up at the same time, the system ensures that the final result is the same as if they were all run in some sequential order.

File Locking A central lock manager is generally deployed for synchronizing access to shared files. The complexity in locking comes from the need to allow concurrent access to the same file. A great number of different locks exist, and moreover, the granularity of locks may also differ.

File Locking NFSv4 operations related to file locking

File Locking Lock – Operation lock is used to request a read or write lock on a consecutive range of bytes in a file. – A client will get back an error message if the operation is conflicted with another lock. – A FIFO – ordered list will grant the next lock to the client at the top of the list once the conflicting lock has been removed.

File Locking Lockt – The lockt operation is used to test whether a conflicting lock exists. – In the case of a conflict, the requesting client is informed exactly who is causing the conflict and on which range of bytes. – It can be implemented more efficiently than lock, because there is no need to attempt to open a file.

File Locking Locku – Locku operation removes a lock from a file. Renew – A client requests the server to renew the lease on its lock. Otherwise, the server will automatically remove the lock after a granted specific time.

File Locking Share reservation – An implicit way to lock a file. – Is independent from locking, can be used to implement NFS for Windows – based systems. – When a client opens a file, it specifies the type of access it requires (READ, WRITE or BOTH), and which type of access the server should deny other clients. (NONE, READ, WRITE or BOTH)

File Locking When a client tries to open a file requesting a specific type of access, given the current denial state of that file.

File Locking Show the result of opening a file that is currently being accessed by anther client, but now requesting certain access types to be disallowed.

Sharing Files in Coda The session semantics in NFS dictate that the last process that closes a file will have its changes propagated to the server; any updates in concurrent, but earlier sessions will be lost. To accommodate file sharing, the Coda file system (Kistler and Satyannaryanan, 1992) uses a special allocation scheme that bears some similarities to share reservations in NFS.

Sharing Files in Coda If client A has opened file F for writing, another client B wants to open F as well, it will fail. Because the server records that client A might have modified F. If client A opened file F for reading, the request from client B to read or write the file F would be granted.

Sharing Files in Coda The server only allow one client to modify a file F. – A, B, C and D have all opened file F and only A is allowed to modify. – A modifies F and close the file, the file will be transferred back to the server. – B, C and D are still proceeding to read their local copy.

Sharing Files in Coda B close the file and updated version of F and server send an invalidation message to A.

Future Work As we enter the era of large-scale Chip Multi Processing (CMP) systems, evaluating architectures and projecting performance for commercial workloads on such systems is becoming increasingly important. The future work involves large scale CMP with real workloads and OS scalability studies. There also will be investigating hardware scalability and other software scalability issues beyond locking and synchronization.

Reference 1.Tanenbaum, A., & Van Steen, M. (2006). Distributed Systems Principles and Paradigms (Second ed.). 2. RamyaRani, J., Drishya, S. Varghese, R., & SaravanaGuru, R. Synchronization Algorithms in Distributed File System. International Journal of Innovative Research in Technology & Science(IJIRTS) 3.Jaideep M, Ramesh I, Li Z, Srihari M & Don N. Effect of Locking and Synchronization on Furure Large Scale CMP Platform