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) > - lk locks may be mandatory or advisory. > mandatory mode is not tested for a very long time. > - 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) > (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 Avati
_______________________________________________ Gluster-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/gluster-devel
