GSOC 2015 Aspirant for Improving SMB3 protocol improvements

[Saket Sinha]

Hi Steve,

This is regarding the project implementing Directory oplocks in linux
samba client.

In mainline linux kernel, we have oplocks already implemented for file
operations. Following oplocks are present for files -

OPLOCK_LEVEL_NONE
OPLOCK_LEVEL_II
OPLOCK_LEVEL_EXCLUSIVE
OPLOCK_LEVEL_BATCH
OPLOCK_LEVEL_LEASE


>
> 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
(->s_vfs_rename_mutex).

 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.