[cifs-protocol] Trying to let a Windows client use MS-SWN against a samba cluster #Q6- TrackingID#2311070040010094
Stefan Metzmacher
metze at samba.org
Fri Apr 19 13:26:18 UTC 2024
Hello Sreekanth and others,
currently I don't have time to follow up on all other questions, but this one is actually important.
I would hope that you might forward to the product team.
As it would be extremely useful if windows clients could be changed in order to
avoid logging Event ID: 30900 and Event ID: 30613 for each open
if the server announces SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY but not
SMB2_GLOBAL_CAP_PERSISTENT_HANDLES. See below for the details.
I think in that situation a single log event after a tree connect would be useful as warning,
but doing that on every single open (as all opens will downgrade a requested persistent handle to a durable handle)
is complete overkill.
This will likely make windows client customers very unhappy if they
connect to Samba 4.20 based fileserver clusters.
Thanks for any possible help.
metze
>> 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
>
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at lists.samba.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol
More information about the cifs-protocol
mailing list