[cifs-protocol] [EXTERNAL] Re: Question #3 - Trying to let a Windows client use MS-SWN against a samba cluster

[Sreekanth Nadendla]

Hi Metze, I've verified this and agree with your assessment. A doc change request was submitted and I'll share the draft with you as soon as it is available.


Regards,

Sreekanth Nadendla

Microsoft Windows Open Specifications



________________________________
From: Stefan Metzmacher <metze at samba.org>
Sent: Tuesday, November 21, 2023 7:32 AM
To: Sreekanth Nadendla <srenaden at microsoft.com>
Cc: cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>
Subject: [EXTERNAL] Re: Question #3 - Trying to let a Windows client use MS-SWN against a samba cluster

Hi Sreekanth,

can we please keep cifs-protocol at lists.samba.org cc'ed?

> in your question #3 below, are you saying that client requests for witness registration occurs as long as the capability bits SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY and SMB2_SHARE_CAP_CLUSTER are set ?
>
> In that case which part of the following section is incorrect ?

see the following:

> Note that we have to know if SMB2_SHARE_CAP_ASYMMETRIC bit is set to determine whether a TREE_CONNECT request needs to be sent as mentioned in this section.
>
>
>
> 3.2.5.5 Receiving an SMB2 TREE_CONNECT Response
>
>     ...
>
>     - TreeConnect.IsCAShare MUST be set to TRUE, if the
>       SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY bit is set in the Capabilities
>       field of the response.

I quoted this only to show that SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY
has some side effects not related to witness registrations.
See section 3.2.4.3.5 Application Requests Creating a File Opened for Durable Operation.

>     ...
>
>     If Connection.Dialect belongs to the SMB 3.x dialect family and the Capabilities
>     field in the response includes SMB2_SHARE_CAP_CLUSTER bit, the client SHOULD
>     invoke the event as specified in [MS-SWN] section 3.2.4.1 by providing
>     Connection.ServerName as Netname parameter.

This states the SMB2_SHARE_CAP_CLUSTER alone triggers the witness registration,
but it doesn't happen, the Windows Server 2022 (as client) only tries
the witness registration when SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY and SMB2_SHARE_CAP_CLUSTER
are both set together.

>     ...
>
>     If Connection.Dialect belongs to the SMB 3.x dialect family and the Capabilities
>     field in the response includes the SMB2_SHARE_CAP_SCALEOUT bit, the client MUST
>     set TreeConnect.IsScaleoutShare to TRUE.

This was mainly quoted to show the interaction with section
3.2.4.27 Application Notifies Offline Status of a Server
and question 7...

>     ...
>
>     If Connection.Dialect is "3.0.2" or "3.1.1" and the Capabilities field in the
>     response includes the SMB2_SHARE_CAP_ASYMMETRIC bit, the client MUST verify
>     whether both of the following conditions are true:


I missed the following:

      - Connection.SessionTable contains only one entry.

      - Session.TreeConnectTable contains only one entry.

     If either of the preceding conditions is FALSE, the client MUST perform the following:

     -  Disconnect the tree connection as specified in section 3.2.4.22.

>       ...
>
>       If the SMB2 TREE_CONNECT request is successful, the client SHOULD invoke the
>       event as specified in [MS-SWN] section 3.2.4.1 by providing
>       Connection.ServerName as the Netname parameter and TreeConnect.ShareName as the
>       ShareName parameter, and by setting the IsShareNameNotificationRequired
>       parameter to TRUE.

I only tested with a single share connection.
I just retested with connections to more than one share
and I'm now seeing witness registrations for each share.

So SMB2_SHARE_CAP_ASYMMETRIC does alter the behavior,
but it has no effect without SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY
and SMB2_SHARE_CAP_CLUSTER.

Thanks!
metze
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20231204/44e6d022/attachment.htm>