GSOC 2015 Aspirant for Improving SMB3 protocol improvements
saket.sinha89 at gmail.com
Mon Mar 23 04:53:04 MDT 2015
This is regarding the project implementing Directory oplocks in linux
In mainline linux kernel, we have oplocks already implemented for file
operations. Following oplocks are present for files -
> 2) Directory oplocks:
> Advantage: will reduce network load a lot in some workloads, and improve performance as well. Works with recent Windows servers (Windows 2012 and later e.g.)
> Disadvantage: Samba does not support it yet (although this might help drive changes to the Server and Linux VFS eventually, if we have client support).
Locking scheme used for directory operations is based on two kinds of
locks - per-inode (->i_mutex) and per-filesystem
When taking the i_mutex on multiple non-directory objects, we always
acquire the locks in order by increasing address. We'll call that
"inode pointer" order in the following.
For our purposes all operations fall in 5 classes:
1) read access. Locking rules: caller locks directory we are accessing.
2) object creation. Locking rules: same as above.
3) object removal. Locking rules: caller locks parent -> finds victim
-> locks victim and calls the method.
4) rename() that is _not_ cross-directory.
Locking rules: caller locks the parent and finds source and target.
If target already exists, lock it. If source is a non-directory, lock
it. If that means we need to
lock both, lock them in inode pointer order.
5) link creation.
Locking rules: lock parent -> check that source is not a directory ->
lock source -> call the method.
6) cross-directory rename. The trickiest in the whole bunch.
Locking rules: lock the filesystem -> lock parents in "ancestors
first" order -> find source and target -> if old parent is equal to
or is a descendent of target fail with -ENOTEMPTY -> if new parent is
equal to or is a descendent of source fail with -ELOOP -> If target
exists, lock it. If source is a non-directory, lock it. In case that
means we need to lock both source and target, do so in inode pointer
order -> call the method.
So here we would be attempting to implement all of these directory
operations, by the same oplocks that we use for file operations.
I would request you to let me know whether my understanding is correct
and which task to choose to get started.
More information about the samba-technical