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