GSOC 2015 Aspirant for Improving SMB3 protocol improvements

Steve French smfrench at
Wed Mar 25 12:16:27 MDT 2015

On Mon, Mar 23, 2015 at 5:53 AM, Saket Sinha <saket.sinha89 at> wrote:
> 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
> (->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.

Directory oplocks are likely to be an extension of the actimeo
metadata caching on the client.

Note that the kernel does not have an exact equivalent for directory
oplocks but that does not prevent cifs.ko from returning cached inode
data (or even cached directory leases) on directories for which we
have been granted a read-only directory oplock.  Some of the places
that we cache inode data are controlled by actimeo (we cache for about
a second, a little stricter than most network file systems but this
would allow us to cache safely for longer periods).  We will also need
a mount option to disable directory leases (to work around a buggy
server e.g.).

Probably easiest thing to do is take two Windows machines (at least
Windows 8 or later) and trace network traffic accessing files, listing
directory contents in a directory (and repeating a couple of times),
and then do the same thing to a Samba server from the same client.
You should see differences in the number of query info calls (due to
Windows supporting directory leases).

Also FYI - I have created a status wiki page for the SMB3
implementation in the kernel client  (although needs various
corrections and additions)



More information about the samba-technical mailing list