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 <[email protected]> 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.
_______________________________________________ Gluster-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/gluster-devel
