GSOC 2015 Aspirant for Improving SMB3 protocol improvements

Saket Sinha saket.sinha89 at
Mon Mar 23 04:53:04 MDT 2015

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 -


> 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 mailing list