Latest version 3.8 from GlusterFS community comes out with the support for Mandatory locks. Please refer the blog post announcing the release to get an overview of all new features delivered with 3.8. This article will be a background cum architectural analysis on mandatory locks feature for GlusterFS and its further possibilities when working under various protocol environments.
Traditional/Advisory locks
Whenever it comes to a situation where file contents are being concurrently accessed by different applications there always raise the question of data integrity. It is the sole responsibility of a file system to provide a mechanism that restricts access to different byte ranges of a file in such a way that correct data is being processed by end-user applications. Obviously this was thought well before and we do have locks or more precisely advisory locks which provides the above mentioned feature to the upper file system layer which can be consumed by applications. This would mean that individual byte-ranges/records within any given file may be locked by a particular process before it reads from or write into the particular region. Apart from the process holding the lock, in order to maintain the data integrity, it is assumed that other processes can only modify the same byte range with a lock being held on the region. Thus we ensure that no stale data is being consumed by applications. This has been standardized by POSIX and is being widely used by numerous applications. See fcntl(2) for more details on how to request for byte range locks. On the other hand, this cooperative locking approach can lead to issues when a process starts modifying file contents without considering the lock currently held by other processes. As a result some Unix-like operating systems including Linux offers a limited support for mandatory locks.
Mandatory locks
Now we are aware of the consequences caused by a badly written application dishonouring byte range locks in a file system. Even though mandatory locks were introduced as a solution, its capabilities are limited in the sense that it opens window for some race conditions which can eventually lead to data corruption. Mandatory locks design induces the responsibility of checking the attempts by a process to modify bytes of a file on which another process holds lock at the same time. You can read on how this logic is implemented within linux kernel VFS(Virtual File System) and its potential race windows here.
POSIX locks implementation for GlusterFS
Locks being an integral part of a file system GlusterFS was also designed to act in a similar way as any POSIX-complaint file system would take care of byte range locks. Sticking with the fact that GlusterFS is a user-space file system without any kernel-level complexities the whole fcntl lock implementation is integrated within the GlusterFS layer itself so that VFS layer is unaware of the locks being requested from the application side. Even though GlusterFS lacks the capability for detecting dead locks to my knowledge it satisfies every other requirements as expected from a normal underlying POSIX file system.
Mandatory locks + GlusterFS
Since we have integrated POSIX locks within GlusterFS stack why don’t we extend the same to make it work with mandatory type of locks? Well, here we have to think of yet another kind of locking strategy used by SMB or Microsoft Windows based applications. While designing a specification to have this support for GlusterFS it is indeed necessary to cope with different protocol clients like NFS, SMB etc. Moreover providing a generic solution to a problem will always gift benefits in future. Efforts were taken from this point of view and a design specification was accepted upstream whose implementation got completed with latest release 3.8. For more details on how to configure GlusterFS volumes to effectively make use of this feature can be found at Administration Guide here.
What’s next?
Citing an example use case, we have talked about SMB clients in the previous section but we mentioned nothing on how Windows clients can make use of this feature(click here to get an overview on how GlusterFS volumes are accessed via SMB clients). Yes..you guessed it right. We need libgfapi support. Chances are that this additional API will soon be available with next minor update for 3.8(tracker).
Finally, GlusterFS community needs your feedback. So get your hands on to it and try out the new exciting features. Reach out for help regarding issues via mailing lists(gluster-users@gluster.org and gluster-devel@gluster.org) or irc channels(#gluster and #gluster-dev on freenode).
Openforums 