Directory Leasing feature in Samba smbd

[Krishna Harathi]

To make it clear, steps I listed are for the setup I wanted to test *before* adding test-cases to Samba. Our vested interest in this feature is purely due to the fact that the windows client seems to take advantage of this directory leasing by caching and thus improving the response time of a specific workload. So I need
to setup this workload that first works with native windows SMB implementation . The same setup eventually should also works with Samba smbd for us once directly lease is implemented. 

On the matter of adding test cases to Samba torture set, I completely agree with what you and Jeremy pointed out. It will/should be based only on SMB2/3 protocol request/response interaction. There is no intent to make the client-caching  and other aspects of the above setup as part of samba directory leasing tests.


Regards.
Krishna Harathi
 

On 9/3/20, 7:42 AM, "samba-technical on behalf of Tom Talpey via samba-technical" <samba-technical-bounces at lists.samba.org on behalf of samba-technical at lists.samba.org> wrote:

    ***EXTERNAL SENDER. Only open links and attachments from known senders. DO NOT provide your username or password.***

    On 9/2/2020 5:16 PM, Jeremy Allison via samba-technical wrote:
    > On Wed, Sep 02, 2020 at 04:27:54PM -0400, Tom Talpey via samba-technical wrote:
    >> On 9/2/2020 3:20 PM, Jeremy Allison via samba-technical wrote:
    >>> On Wed, Sep 02, 2020 at 05:18:05PM +0000, Krishna Harathi wrote:
    >>>> Jeremy,
    >>>>
    >>>> Thanks for the insightful response on how to start on directory leasing feature.
    >>>>
    >>>> After reading more into Microsoft SMB2/3 directory leasing, in our customer case, looks like the windows client is taking advantage of the granted directory lease and maintaining a directory cache.
    >>>>
    >>>> I am attempting to setup the following even before writing test cases.
    >>>>
    >>>>     1. Using directory lease capable Windows Server 2012R2 (or later), setup a shared folder/directory with a set of files/folders in it.
    >>>>     2. On a Windows client capable of using directory lease , map the shared folder to a local drive letter.
    >>>>     3.  Start capturing tcpip packets on either client or server.
    >>>>     4. Browse the shared folder on the client multiple times.
    >>>>     5. The tcpip dump should show only a single directory scan set (SMB2_FIND_BOTH_DIRECTORY_INFO requests/responses)
    >>>>
    >>>> Is my assumption and approach correct? Is there a better/direct way to monitor the directory lease and cache in the client?
    >>>>
    >>>> Only information I found on Windows is the global configuration values of "DirectoryCacheEntriesMax" and "DirectoryCacheEntrySizeMax" shown with powershell "get-smbclientconfiguration". Are there any stats to monitor to determine that the directory cache is active with entries from the mapped drive that has the directory leased?
    >>>>
    >>>> Once this setup is done and confirmed working, I will have a better understanding on what to expect and I will start adding test cases to smb torture.
    >>>
    >>> Hi Krishna,
    >>>
    >>> That would seem to be a good way to explore
    >>> how the Windows client behaves. I don't have
    >>> good insights into how the Windows client
    >>> manages its cache I'm afraid.
    >>
    >> I think it's a very risky thing to assert that any particular caching
    >> occurs. There is no protocol requirement for caching, so the behavior
    >> of the client is purely an implementation choice.
    >>
    >> It's great to explore but "adding test cases to smb torture" is my
    >> concern. What kind of test cases?
    >
    > The same kind of test cases we used to determine the behavior
    > of leases on files.
    >
    > a). Open a directory with lease, different varients of RWH etc.
    > b). Try opening a directory with an oplock (does that work?)
    > c). Try creating a file in the directory via a second connection,
    > watch for the break traffic on the handle etc.
    >
    > We're not planning to test the client caching, as you say that's
    > a client policy decision.

    Sounds good. But my concern is triggered by this statement in the
    original message:

     >>>>     5. The tcpip dump should show only a single directory scan set
    (SMB2_FIND_BOTH_DIRECTORY_INFO requests/responses)

    But there's no guarantee this will be the case. A large directory, or
    memory pressure, or any other condition may cause a scan. If the server
    returns a lease on a directory handle, that's about all that can be
    concluded per the protocol.

    There is also some bit in the share flags about cachability, but I'm not
    sure if anything is required to look at it.

    Tom.