[cifs-protocol] Trying to let a Windows client use MS-SWN against a samba cluster #Q6- TrackingID#2311070040010094
Stefan Metzmacher
metze at samba.org
Thu Jan 4 15:58:31 UTC 2024
Hello Sreekanth,
> below is the answer to your question #6. Let me know your thoughts.
Thanks for the response!
> Please note that section 3.2.4.3.5 did not say MUST. It only uses SHOULD. Also, the wording of the section does NOT imply that when requesting durable handle, one cannot request handle caching if TreeConnect.IsCAShare is FALSE.
And in fact I have captures showing that Windows server 2022 acting as a client requests with the SMB2_DHANDLE_FLAG_PERSISTENT and also an RHW leaveV2.
> A client can request both Persistence and Lease (with handle caching enabled). Protocol(or windows) server does not deny granting both persistence and lease, when the requirements are met.
>
> Protocol says that in order to request durable open, client should either set SMB2_DHANDLE_FLAG_PERSISTENT bit in the Flags field of Durable_V2 create context or request for handle caching with Lease create context.
>
> If the share is a CA share (in a Failover Cluster configuration), client can request for handle persistency by setting SMB2_DHANDLE_FLAG_PERSISTENT bit which provides transparent failover.
>
> Please look at the doc snip from section 3.3.5.9.10, where both TreeConnect.Share.IsCA (SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY) and SMB2_GLOBAL_CAP_PERSISTENT_HANDLES are required in order to set Open.IsPersistent to TRUE. This is a server requirement though.
Yes, the server is clear how our server will behave, but that case is never possible on a windows server (which always implements both features).
> On the client side, it is imperative that CA shares will require persistence handles to work with. In other words, for the server to grant persistent handle on an open, client must set SMB2_GLOBAL_CAP_PERSISTENT_HANDLES.
>
> In the "Successful Open Initialization" phase, if the underlying object store does not grant durability, the server MUST skip the rest of the processing in this section. Otherwise, the server MUST set Open.IsDurable to TRUE. The server MUST also set Open.DurableOwner to a security descriptor accessible only by the user represented by Open.Session.SecurityContext. If the SMB2_DHANDLE_FLAG_PERSISTENT bit is set in the Flags field of the request, TreeConnect.Share.IsCA is TRUE, and Connection.ServerCapabilities includes SMB2_GLOBAL_CAP_PERSISTENT_HANDLES, the server MUST set Open.IsPersistent to TRUE.
Yes, that's clear.
But it means the client will spam its event log (SMBClient->Operational) with messages like this
for every single open:
> Log Name: Microsoft-Windows-SMBClient/Operational
> Source: Microsoft-Windows-SMBClient
> Date: 22.12.2023 13:41:18
> Event ID: 30900
> Task Category: None
> Level: Warning
> Keywords: (16)
> User: W2022-L7\Administrator
> Computer: w2022-118.w2022-l7.base
> Description:
> The handle was created without persistence.
>
> File ID: 0xB90243FF:0x5367F848
> CreateGUID: {80c941d9-a0bd-11ee-81fc-000000090118}
> Path: \ubcluster.w2022-l7.base\shm
>
> Guidance:
> The server supports Continuous Availability (persistent handles) and the request to create the handle succeeded. However, the server did not grant persistence. You should verify that the Resume Key Filter is running on the server and is attached to the target volume.
> Event Xml:
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
> <System>
> <Provider Name="Microsoft-Windows-SMBClient" Guid="{988c59c5-0a1c-45b6-a555-0c62276e327d}" />
> <EventID>30900</EventID>
> <Version>2</Version>
> <Level>3</Level>
> <Task>0</Task>
> <Opcode>0</Opcode>
> <Keywords>0x2000000000000010</Keywords>
> <TimeCreated SystemTime="2023-12-22T12:41:18.6300118Z" />
> <EventRecordID>335</EventRecordID>
> <Correlation />
> <Execution ProcessID="1616" ThreadID="4712" />
> <Channel>Microsoft-Windows-SMBClient/Operational</Channel>
> <Computer>w2022-118.w2022-l7.base</Computer>
> <Security UserID="S-1-5-21-133451344-1126667713-3548050118-500" />
> </System>
> <EventData>
> <Data Name="Object">0xffffb68432192080</Data>
> <Data Name="PersistentFID">3103933439</Data>
> <Data Name="VolatileFID">1399322696</Data>
> <Data Name="CreateGUID">{80c941d9-a0bd-11ee-81fc-000000090118}</Data>
> <Data Name="OldState">3</Data>
> <Data Name="NewState">0</Data>
> <Data Name="Status">0</Data>
> <Data Name="Reason">0</Data>
> <Data Name="ShareNameLength">28</Data>
> <Data Name="ShareName">\ubcluster.w2022-l7.base\shm</Data>
> <Data Name="ObjectNameLength">0</Data>
> <Data Name="ObjectName">
> </Data>
> <Data Name="PreviousStatus">0</Data>
> <Data Name="PreviousReason">0</Data>
> </EventData>
> </Event>
>
And/or:
> Log Name: Microsoft-Windows-SMBClient/Operational
> Source: Microsoft-Windows-SMBClient
> Date: 22.12.2023 18:28:09
> Event ID: 30613
> Task Category: None
> Level: Error
> Keywords: (16)
> User: W2022-L7\Administrator
> Computer: w2022-118.w2022-l7.base
> Description:
> Failed to open a persistent handle.
>
> Error: The network path cannot be located.
>
> FileId: 0xFFFFFFFFFFFFFFFF:0xFFFFFFFFFFFFFFFF
> CreateGUID: {80c94430-a0bd-11ee-81fc-000000090118}
> Path: \ubcluster.w2022-l7.base\shm
>
> Reason: Smb2DiagReasonNetworkConnect
>
> Guidance:
> A persistent handle allows transparent failover on Windows File Server clusters. This event has many causes and does not always indicate an issue with SMB. Review online documentation for troubleshooting information.
> Event Xml:
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
> <System>
> <Provider Name="Microsoft-Windows-SMBClient" Guid="{988c59c5-0a1c-45b6-a555-0c62276e327d}" />
> <EventID>30613</EventID>
> <Version>0</Version>
> <Level>2</Level>
> <Task>0</Task>
> <Opcode>0</Opcode>
> <Keywords>0x2000000000000010</Keywords>
> <TimeCreated SystemTime="2023-12-22T17:28:09.8627152Z" />
> <EventRecordID>345</EventRecordID>
> <Correlation />
> <Execution ProcessID="1616" ThreadID="2856" />
> <Channel>Microsoft-Windows-SMBClient/Operational</Channel>
> <Computer>w2022-118.w2022-l7.base</Computer>
> <Security UserID="S-1-5-21-133451344-1126667713-3548050118-500" />
> </System>
> <EventData>
> <Data Name="Object">0xffffb6842f0241d0</Data>
> <Data Name="PersistentFID">18446744073709551615</Data>
> <Data Name="VolatileFID">18446744073709551615</Data>
> <Data Name="CreateGUID">{80c94430-a0bd-11ee-81fc-000000090118}</Data>
> <Data Name="OldState">3</Data>
> <Data Name="NewState">9</Data>
> <Data Name="Status">3221225662</Data>
> <Data Name="Reason">4</Data>
> <Data Name="ShareNameLength">28</Data>
> <Data Name="ShareName">\ubcluster.w2022-l7.base\shm</Data>
> <Data Name="ObjectNameLength">0</Data>
> <Data Name="ObjectName">
> </Data>
> <Data Name="PreviousStatus">0</Data>
> <Data Name="PreviousReason">0</Data>
> </EventData>
> </Event>
Once people will make use of Samba servers without persistent handles,
they will start to see these and I'm not sure how useful that would be
on the windows client side.
>
> * - - - - ORIGINAL TEXT FROM METZE - - - -
>
> 3.2.4.3.5 Application Requests Creating a File Opened for Durable Operation
>
> ...
>
> - If TreeConnect.IsCAShare is TRUE, the client MUST set the
> SMB2_DHANDLE_FLAG_PERSISTENT bit in the Flags field. Otherwise, the client SHOULD
> perform one of the following:
A windows behavior note would be useful for that case. As the 'Otherwise'
confused me and I see no reason why a client should not ask for leases
together with persistent handle, luckily a windows client doesn't obey that SHOULD,
because it would mean a possible performance regression for the client.
> - Request a batch oplock by setting RequestedOplockLevel in the create request to
> SMB2_OPLOCK_LEVEL_BATCH.
>
> - Request a handle caching lease by including an SMB2_CREATE_REQUEST_LEASE or
> SMB2_CREATE_REQUEST_LEASE_V2 Create Context in the create request with a
> LeaseState that includes SMB2_LEASE_HANDLE_CACHING.
>
> ...
>
> Question 6:
> From the documentation the above is the only reference that is impacted by SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY and it seems that it implicitly disables handle caching, is that really true?
>
> And SMB2_DHANDLE_FLAG_PERSISTENT doesn't seem to be impacted by
> SMB2_GLOBAL_CAP_PERSISTENT_HANDLES, which is strange.
> Can you please cross-check this?
I think something also causes the client to send tcp keepalives every 10 seconds
and I guess that's also a side effect of SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY.
I guess it may also influence the retry behavior on the client side
Can you please check and document that (at least as product behavior note).
Thanks
metze
More information about the cifs-protocol
mailing list