[LSF/MM ATTEND] distributed file locking

Alexander Aring <[email protected]>
Newsgroups dev.linux.lists.gfs2,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-nfs
Message-ID <CAK-6q+gVhsKKPPax52nju8HXPApPyO9zE_jUygDxvhF8BT8P9Q@mail.gmail.com>
Hi,

this proposal for LSF/MM aims to start an initial process to discuss
improving the distributed file locking API in file_operations.
Initially the file locking API, used from the user space via flock()
or fcntl(), was not designed for distributed locking. There are known
issues e.g. specifying a process id but missing additional information
about the distributed entity where the process is running.

There should be a way for users to opt into additional distributed
locking extensions that provide specific distributed locking info or
even introduce a new file ops distributed locking API. Designing such
new behaviour requires community effort to become aware of all
distributed locking use cases in the Linux kernel. Examples of those
users include DLM, NFS or CIFS.

A recent proposal [0] suggested offering the file locking API only to
the user through a virtual filesystem, using DLM as the distributed
lock manager backend for now. The filesystem's concept can be extended
to offer other backends and allow experiments with new "distributed"
file locking API extensions until the community agrees on and proposes
a stable API.

This proposal discusses an exotic and very specific topic: distributed
file locking, which tries to map to the existing file locking API.
Users working on distributed file systems are aware of the challenges
involved. Solving those long-standing challenges will be a lengthy
process. It might be time to start improving this situation.

Please feel free to share your thoughts on this topic.

- Alex

[0] https://lore.kernel.org/linux-fsdevel/[email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.