<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body>
<pre>Thank you very much.</pre>
<pre> </pre>
<pre>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.</pre>
<pre> </pre>
<pre>Thanks</pre>
<pre> </pre>
<pre>On 01.03.2012 18:07, Anand Avati wrote:</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<pre>Please find answers inline.
On Wed, Feb 29, 2012 at 7:16 AM, Xavier Hernandez <<a href="mailto:xhernandez@datalab.es">xhernandez@datalab.es</a>> wrote:</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">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 ?</blockquote>
<pre>Reserve lock was an experimental feature introduced for the
requirements of an initial lock self healing design. It is unused now.</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">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 ?</blockquote>
<pre>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.</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">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 ?</blockquote>
<pre>The main difference between the two is that readdir returns entries
(just names) while readdirp returns along with entry names - handles
and attributes. Setting the dict_t parameter to NULL has no difference
in this behaviour. You can see the posix_readdir/p functions in
xlators/storage/posix/src/posix.c to see the actual difference between
the two calls.
Thanks
Avati
</pre>
</blockquote>
</body></html>