Directory Leasing feature in Samba smbd

[Tom Talpey]

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.