[prev in list] [next in list] [prev in thread] [next in thread]
List: cifs-protocol
Subject: Re: [cifs-protocol] Trying to let a Windows client use MS-SWN against a samba cluster #Q6- TrackingI
From: Stefan Metzmacher via cifs-protocol <cifs-protocol () lists ! samba ! org>
Date: 2024-04-19 13:26:18
Message-ID: 030a9e2b-482e-4913-92a7-5edbc59c2e67 () samba ! org
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic