[Gluster-devel] locking

[Xavier Hernandez]

Thank you very much.

In readdirp I always receive a NULL pointer
from upper translators. I tried to set it to a list of extended
attributes but I didn't receive anything in the field 'dict' in
gf_dirent_t when the callback was called. Looking again into the posix
code I can see that it really should fill in the requested attributes,
so probably I made some error when I tested this. I will repeat the
tests.

Thanks

On 01.03.2012 18:07, Anand Avati wrote:

> Please find
answers inline.
> 
> On Wed, Feb 29, 2012 at 7:16 AM, Xavier Hernandez
<xhernandez at datalab.es> wrote:
> 
>> 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 ?
> 
> Reserve lock was an experimental
feature introduced for the
> requirements of an initial lock self
healing design. It is unused now.
> 
>> 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 ?
> 
> l_pid and l_owner are really
useful only in the GETLK call to identify
> the owner of a lock on a
given region. For SETLK operations it is
> frame->root->{pid,lk_owner}
that get used for the purpose of lock
> granting.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120301/e253f3f2/attachment-0003.html>