Synchronization in Distributed File System Swathi Kiran Reddy Pallamreddy Dr. Yanqing Zhang

Overview Semantics of File Sharing. File Locking Sharing File in Coda Future Work Reference

Semantics of File Sharing On a single processor, when a read follows a write, the value returned by the read is the value just written.

In a distributed system with caching, obsolete values may be returned. 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.

Four ways of dealing with the shared files in a distributed system. UNIX Semantics Session Semantics Immutable files Transactions

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

Session semantics Changes to an open file are initially visible only to the process (or possibly machine) that modified the file. Only when the file is closed are the changes made visible to other processes.

Immutable Files Make all files immutable. The only operations on files are create and read. It becomes impossible to modify the file x but It can be replaced by a new file with the same name. Although files cannot be updated, directories can be.

transactions To access a file or a group of files, a process first executes BEGIN_TRANSACTION primitive to signal that what follows must be executed separately. When the requested work has been completed, an END_TRANSACTION primitive is executed. All the calls within the transaction are processed in order. If two or more transactions start up at the same time, the final result is the same as if they were all run in some sequential order.

File Locking The traditional way of doing this is to make use of a lock manager which follows a centralized locking scheme. Although a central lock manager is generally deployed, the complexity in locking comes from the need to allow concurrent access to the same file. For this reason we will be using NFSv4.

NFSv4 operations related to file sharing

Lock Operation lock is used to request a read or write lock on a consecutive range of bytes in a file. If the lock cannot be granted due to another conflicting lock, the client gets back an error message. The client can request to be put on FIFO list. As soon as the conflicting lock has been removed, the server will grant the next lock to the client at the top of the list

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. Locku The lockt operation is used to remove a lock from a file.

Renew The renew operation used by a client to request the server to renew the lease on its lock. Unless the client renews the lease on a lock it has been granted, the server will automatically remove it.

Share reservation An implicit way to lock a file. Is independent from locking, can be used to implement NFS for Windows – based systems. When an OPEN request is sent for a file, the requester can indicate the type of access that should be denied to other requesters attempting to access the same file, which is NONE, READ, WRITE or BOTH.

Sharing files in coda The Coda file system uses a special allocation scheme that bears some similarities to share reservations in NFS. When a client opens a file, an entire copy of the file is transferred to the client’s machine. The server records that the client has a copy of the file.

Now if client A has opened file F for writing and another client B wants to open F as well, it will fail. This failure is caused by the fact that the server has recorded that client A might have already modified F. On the other hand, had client A opened F for reading, an attempt by client B to get a copy from the server for reading would succeed. An attempt by B to open for writing would succeed as well.

Only one client will be able to modify F at a time Only one client will be able to modify F at a time. If this client modifies F and subsequently closes the file, the file will be transferred back to the server. However, every other client may proceed to read its local copy despite the fact that the copy is actually outdated. Reason for this inconsistent behavior is that a session is treated as a transaction in Coda.

Assume A has opened F for reading, leading to session SA· Client B has opened f for writing, that is session S8· When B closes session S8' it transfers the updated version of f to the server, which will then send an invalidation message to A. A will now know that it is reading from an older version of F.

Future Work Currently most of the researches are concentrated on cloud-based synchronization of distributed file system. As the number of user-managed devices continues to increase, the need for synchronizing multiple file hierarchies distributed over devices with ad hoc connectivity, is becoming a significant problem. My future work is to research on an approach for efficient cloud- based synchronization of an arbitrary number of distributed file system hierarchies.

References Tanenbaum, A., & Van Steen, M. (2006). Distributed Systems Principles and Paradigms (Second ed.). Distributed File Systems, http://pages.cs.wisc.edu/~sschang/OS- Qual/fs/distributed_file_systems.htm Cloud-based synchronization of distributed file system hierarchies, Sandesh Uppoor, Michail D. Flouris & Angelos Bilas, (20-24 Sept. 2010), Publisher: IEEE

Thank YOU !!