[Gluster-devel] locking

Xavier Hernandez xhernandez at datalab.es
Wed Feb 29 15:16:23 UTC 2012

Hello gluster developers,

I'm working on a new translator that needs to implement locking 
strategies over inodes and directory entries for some file operations. 
The translator uses multiple subvolumes.

I've been searching internet and browsing source code but there are 
some aspects that I can't completely understand.

First of all I've noticed that there are 3 kinds of locks. Two of them 
are easy to understand: inode and entry locks. But there is another kind 
of lock that I don't understand how it is used or what is its purpose. 
It's called 'reserve lock'. Can you explain me what is the rationale of 
this lock, how it's used and what I have to do if I receive it from an 
upper translator ?

Regarding inode locks, the structure gf_flock has basic fields that 
define the type and range of the lock (l_type, l_whence, l_start and 
l_len). There are two other fields (l_pid and l_owner) that I thought 
were used to identify the owner of the lock. However it seems to be not 
used in features/locks translator. It uses the pid and owner taken from 
call_stack_t.lk_owner and call_stack_t.pid from the current frame. Also, 
cluster/afr translator uses this fields when it creates locks.

Are really l_pid and l_owner of structure gf_flock unused ?

Another unrelated question... there are two fops very similar: readdir 
and readdirp. The only difference between them is an additional dict_t 
argument. It seems that it contains parameters, but I don't know to what 
purpose. While running my translator I only receive readdirp requests 
from upper translators, but the dict_t argument is always NULL. Is 
really readdir functionally equivalent to readdirp with this argument 
set to NULL ? Do I need to have any especial handling of this argument ?

Thanks in advance for your help.


More information about the Gluster-devel mailing list