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
_______________________________________________
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
