locking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Xavi



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux