This session covers entrylks and interaction between entrylk and inodelk in deletion code paths of glusterfs

1. Glusterfs Session #11
Locks xlator entrylks

2. Scope
- What is the behavior of entrylks
- Code walk through of entrylks
- Dependency of entrylk, inodelk
- Optimization of the interaction

3. Behavior of entrylks
- To recap, entrylks are used to synchronize entry operations on directories.
- In inodelks range(offset, length) is what we synchronize on. In entrylks we
synchronize on the name.
- In entrylks NULL name represents full directory lock

4. Behavior of entrylks
If names are different they are granted irrespective of the lk-owner/client
Directory dir1
Name1 Name2
Directory: dir1

5. Behavior of entrylks
If names are conflicting they are not granted if the lk-owner/client differs
Directory dir1
Name1 Name1
Directory: dir1

6. Behavior of entrylks
If names are conflicting they are not granted if the lk-owner/client differs
Directory dir1
Name1 NULL(value)
Directory: dir1

7. Behavior of entrylks
If names are not conflicting they are granted if the lk-owner, client matches
Directory dir1
Name1 Name1
Directory: dir1

8. Behavior of entrylks
If names are same they are granted if the lk-owner, client matches
Directory dir1
Name1 NULL(value)
Directory: dir1

9. Code walk through

10. Dependency of entrylk, inodelk
- When doing parallel operations on EC, we sometimes faced this issue where
by the time inode is going to be unlocked, entry is already removed leading to
issues while doing operations on the inode
- https://github.com/gluster/glusterfs/issues/990
- There was no synchronization between entry operations and inode operations

11. Solution
- Block entry deletion until inodelk is unlocked.
- Code walkthrough

12. Q & A