Re: Connection sharing in SMB multichannel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Aurélien Aptel <aurelien.aptel@xxxxxxxxx> writes:

> Hey Shyam,
>
> I remember thinking that channels should be part of the server too
> when I started working on this but switched it up to session as I kept
> working on it and finding it was the right choice.
> I don't remember all the details so my comments will be a bit vague.
>
> On Tue, Jan 10, 2023 at 10:16 AM Shyam Prasad N <nspmangalore@xxxxxxxxx> wrote:
>> 1.
>> The way connections are organized today, the connections of primary
>> channels of sessions can be shared among different sessions and their
>> channels. However, connections to secondary channels are not shared.
>> i.e. created with nosharesock.
>> Is there a reason why we have it that way?
>> We could have a pool of connections for a particular server. When new
>> channels are to be created for a session, we could simply pick
>> connections from this pool.
>> Another approach could be not to share sockets for any of the channels
>> of multichannel mounts. This way, multichannel would implicitly mean
>> nosharesock. Assuming that multichannel is being used for performance
>> reasons, this would actually make a lot of sense. Each channel would
>> create new connection to the server, and take advantage of number of
>> interfaces and RSS capabilities of server interfaces.
>> I'm planning to take the latter approach for now, since it's easier.
>> Please let me know about your opinions on this.
>
> First, in the abstract models, Channels are kept in the Session object.
> https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/8174c219-2224-4009-b96a-06d84eccb3ae
>
> Channels and sessions are intertwined. Channels signing keys depend on
> the session it is connected to (See "3.2.5.3.1 Handling a New
> Authentication" and "3.2.5.3.3 Handling Session Binding").
> Think carefully on what should be done on disconnect/reconnect.
> Especially if the channel is shared with multiple sessions.
>
> Problem with the pool approach is mount options might require
> different connections so sharing is not so easy. And reconnecting
> might involve different fallbacks (dfs) for different sessions.

AFAICT, for a mount with N channels, whether DFS or not, there is a
wrong assumption that after failover, there will be N channels to be
reconnected.

There might be a case where the administrator disabled multichannel in
server settings, or decreased the number of available adapters, or if
the new DFS target doesn't support multichannel or has fewer channels.
In this case, cifs.ko would have stale channels trying to reconnect
indefinitely.

Please correct me if I missed something.




[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux