[Gluster-devel] New locking strategy

[Xavier Hernandez]

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.
- inodelk and entrylk locks are always mandatory.
- lk locks may be mandatory or advisory.
- 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 (if a write 
request from user is allowed to pass without using inodelk, it won't be 
blocked by a previous inodelk).

Is this interpretation correct and complete ?

Thanks for your help,

Xavi