mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-11-01 00:48:50 +00:00
01945fa248
We (the Ocfs2 project) recently moved the location of our ocfs2-tools git tree and project web page. The pertinent discussion can be seen here: https://oss.oracle.com/pipermail/ocfs2-devel/2015-February/010579.html The following patch updates the Ocfs2 documentation in MAINTAINERS, ocfs2.txt, and dlmfs.txt. I added our new official web page, changed the location of our tools git tree and removed the link to Joel's ancient kernel git tree - Andrew has handled our patches for a while now. Signed-off-by: Mark Fasheh <mfasheh@suse.de> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
130 lines
4.2 KiB
Text
130 lines
4.2 KiB
Text
dlmfs
|
|
==================
|
|
A minimal DLM userspace interface implemented via a virtual file
|
|
system.
|
|
|
|
dlmfs is built with OCFS2 as it requires most of its infrastructure.
|
|
|
|
Project web page: http://ocfs2.wiki.kernel.org
|
|
Tools web page: https://github.com/markfasheh/ocfs2-tools
|
|
OCFS2 mailing lists: http://oss.oracle.com/projects/ocfs2/mailman/
|
|
|
|
All code copyright 2005 Oracle except when otherwise noted.
|
|
|
|
CREDITS
|
|
=======
|
|
|
|
Some code taken from ramfs which is Copyright (C) 2000 Linus Torvalds
|
|
and Transmeta Corp.
|
|
|
|
Mark Fasheh <mark.fasheh@oracle.com>
|
|
|
|
Caveats
|
|
=======
|
|
- Right now it only works with the OCFS2 DLM, though support for other
|
|
DLM implementations should not be a major issue.
|
|
|
|
Mount options
|
|
=============
|
|
None
|
|
|
|
Usage
|
|
=====
|
|
|
|
If you're just interested in OCFS2, then please see ocfs2.txt. The
|
|
rest of this document will be geared towards those who want to use
|
|
dlmfs for easy to setup and easy to use clustered locking in
|
|
userspace.
|
|
|
|
Setup
|
|
=====
|
|
|
|
dlmfs requires that the OCFS2 cluster infrastructure be in
|
|
place. Please download ocfs2-tools from the above url and configure a
|
|
cluster.
|
|
|
|
You'll want to start heartbeating on a volume which all the nodes in
|
|
your lockspace can access. The easiest way to do this is via
|
|
ocfs2_hb_ctl (distributed with ocfs2-tools). Right now it requires
|
|
that an OCFS2 file system be in place so that it can automatically
|
|
find its heartbeat area, though it will eventually support heartbeat
|
|
against raw disks.
|
|
|
|
Please see the ocfs2_hb_ctl and mkfs.ocfs2 manual pages distributed
|
|
with ocfs2-tools.
|
|
|
|
Once you're heartbeating, DLM lock 'domains' can be easily created /
|
|
destroyed and locks within them accessed.
|
|
|
|
Locking
|
|
=======
|
|
|
|
Users may access dlmfs via standard file system calls, or they can use
|
|
'libo2dlm' (distributed with ocfs2-tools) which abstracts the file
|
|
system calls and presents a more traditional locking api.
|
|
|
|
dlmfs handles lock caching automatically for the user, so a lock
|
|
request for an already acquired lock will not generate another DLM
|
|
call. Userspace programs are assumed to handle their own local
|
|
locking.
|
|
|
|
Two levels of locks are supported - Shared Read, and Exclusive.
|
|
Also supported is a Trylock operation.
|
|
|
|
For information on the libo2dlm interface, please see o2dlm.h,
|
|
distributed with ocfs2-tools.
|
|
|
|
Lock value blocks can be read and written to a resource via read(2)
|
|
and write(2) against the fd obtained via your open(2) call. The
|
|
maximum currently supported LVB length is 64 bytes (though that is an
|
|
OCFS2 DLM limitation). Through this mechanism, users of dlmfs can share
|
|
small amounts of data amongst their nodes.
|
|
|
|
mkdir(2) signals dlmfs to join a domain (which will have the same name
|
|
as the resulting directory)
|
|
|
|
rmdir(2) signals dlmfs to leave the domain
|
|
|
|
Locks for a given domain are represented by regular inodes inside the
|
|
domain directory. Locking against them is done via the open(2) system
|
|
call.
|
|
|
|
The open(2) call will not return until your lock has been granted or
|
|
an error has occurred, unless it has been instructed to do a trylock
|
|
operation. If the lock succeeds, you'll get an fd.
|
|
|
|
open(2) with O_CREAT to ensure the resource inode is created - dlmfs does
|
|
not automatically create inodes for existing lock resources.
|
|
|
|
Open Flag Lock Request Type
|
|
--------- -----------------
|
|
O_RDONLY Shared Read
|
|
O_RDWR Exclusive
|
|
|
|
Open Flag Resulting Locking Behavior
|
|
--------- --------------------------
|
|
O_NONBLOCK Trylock operation
|
|
|
|
You must provide exactly one of O_RDONLY or O_RDWR.
|
|
|
|
If O_NONBLOCK is also provided and the trylock operation was valid but
|
|
could not lock the resource then open(2) will return ETXTBUSY.
|
|
|
|
close(2) drops the lock associated with your fd.
|
|
|
|
Modes passed to mkdir(2) or open(2) are adhered to locally. Chown is
|
|
supported locally as well. This means you can use them to restrict
|
|
access to the resources via dlmfs on your local node only.
|
|
|
|
The resource LVB may be read from the fd in either Shared Read or
|
|
Exclusive modes via the read(2) system call. It can be written via
|
|
write(2) only when open in Exclusive mode.
|
|
|
|
Once written, an LVB will be visible to other nodes who obtain Read
|
|
Only or higher level locks on the resource.
|
|
|
|
See Also
|
|
========
|
|
http://opendlm.sourceforge.net/cvsmirror/opendlm/docs/dlmbook_final.pdf
|
|
|
|
For more information on the VMS distributed locking API.
|