That is correct! On Tue, Apr 3, 2012 at 8:46 AM, Xavier Hernandez <[email protected]>wrote:
> Another question that I forgot... > > inodelk and entrylk locks exists inside a domain. This means that, for > example, each inodelk lock is only visible inside its own domain and won't > block other inodelk requests from other domains, even if they refer to the > same region of the file. Is this correct ? > > Xavi > > > On 04/03/2012 05:20 PM, Xavier Hernandez wrote: > > On 04/03/2012 04:53 PM, Anand Avati wrote: > > > > On Tue, Apr 3, 2012 at 6:20 AM, Xavier Hernandez <[email protected]>wrote: > >> Hello developers, >> >> I'm currently trying to implement a new method for managing inode and >> entry modifications that will be faster (I hope) than the current method >> for the most common cases. To do so I need to know exactly how the locking >> mechanism works. I have been browsing the source code and doing some tests, >> and I would like to be sure that I have understood it correctly before >> continuing. >> >> All information is based on latest qa releases from 3.3 branch. >> >> My understanding is this: >> >> - There are three locking fops: lk, inodelk and entrylk. >> - Client application locks created using fcntl() are received by the >> translators as lk requests. >> - All other functionalities of lk fop are not currently used by any >> translator (I mean F_RESLK_LCK, F_RESLK_LCKW, F_RESLK_UNLCK and F_GETLK_FD). >> - inodelk and entrlylk are only used by AFR to lock inodes or directory >> entries before modification. >> - Translators don't generate lk requests internally. >> - Client application requests cannot directly generate an inodelk or >> entrylk requests. >> > > Correct so far. > > >> - inodelk and entrylk locks are always mandatory. >> > > inodelk and entrylk are always advisory. Never mandatory (at least so > far) > > Sorry, I was thinking one thing and said another. Never mind, it's as I > expected: no request will be blocked by any of these locks (except > themselves) > > > >> - lk locks may be mandatory or advisory. >> > > mandatory mode is not tested for a very long time. > > Ok, I won't waste much time on mandatory locks. > > > >> - lk and inodelk are independent from each other, meaning that a lock >> using lk will not be visible to inodelk and will not block it. inodelk >> won't block lk requests neither. >> - User requests can only be blocked by lk created locks > > > Correct, and only if mandatory locks are enabled (which isn't tested > right now) > > Ok. > > > >> (if a write request from user is allowed to pass without using inodelk, >> it won't be blocked by a previous inodelk). >> >> > inodelks are never mandatory, so the question does not apply > > Ok. > > Thank you very much > > Xavi > > > _______________________________________________ > Gluster-devel mailing > [email protected]https://lists.nongnu.org/mailman/listinfo/gluster-devel > > > _______________________________________________ > Gluster-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/gluster-devel > >
_______________________________________________ Gluster-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/gluster-devel
