To actually use it, we first have to copy symbols over from the dlm build
into the scoutfs source directory. Make that happen automatically for us in
the Makefile.
The only users of locking at the moment are mount, unmount and xattr
read/write. Adding more locking calls should be a straight-forward endeavor.
The LVB based server ip communication didn't work out, and LVBS as they are
written don't make sense in a range locking world. So instead, we record the
server ip address in the superblock. This is protected by the listen lock,
which also arbitrates which node will be the manifest server.
We take and drop the dlm lock on each lock/unlock call. Lock caching will
come in a future patch.
Signed-off-by: Mark Fasheh <mfasheh@versity.com>
Using the new interval tree code we add a tree for each lock status list to
efficiently track ranged requests. Internally, most operations on a
resources lock status list (granted, waiting, converting) then are turned
into operations within a given range.
There is no API change other than a new call, dlm_lock_range() and a new
structure, 'struct dlm_key' to define our range endpoints. Keys can have
arbitrary lengths and are compared via memcmp. A ranged blocking ast type is
defined so that users of dlm_lock_range() can know which range they are
blocking.
A rudimentary test, dlmtest.ko is included.
TODO:
- Update userspace entry points, need to add one for new lock call
- Manage backwards compatibility with network protocol
Signed-off-by: Mark Fasheh <mfasheh@versity.com>
Users pass in a comparison function which is used when endpoints need to be
checked against each other. We also put each ITTYPE local definition on it's
own line to facilitate the use of pointers. An upcoming dlm patch will make
use of this to allow for keyed, ranged locking.
Signed-off-by: Mark Fasheh <mfasheh@versity.com>
Also wire it into the build system. We have to figure out how to get scoutfs
pulling in the right headers but that can wait until we have something more
usable.
Signed-off-by: Mark Fasheh <mfasheh@versity.com>
