If CTDB public addresses (or externally managed virtual/floating IP addresses) are used for multi-channel, then there is the risk of creating a multi-channel session that spans multiple cluster nodes. This is due to the fact that the smb client is not aware that it is talking to a multi-host setup. This situation is something that needs to be prevented by all means, since at least currently the implementation of multichannel in samba is based on the principle that all connections of one multichannel session end up in a single smbd process. Otherwise, data corruption is possible due to lack of coordination. It is important to solve this to be able to offer multichannel in a robust way from an RHGS-cluster. There are several possible approaches, not completely mutually exclusive: First is to prevent connections to a different host to be successful in sesion bind. Second is to change samba to not hand out certain (the floating) addresses in the network_interface_info response if asked on a non-floating IP. On the other hand, if network_interface_info comes in via a floating IP, then only give back this single IP. A possible workaround (for testing purposes) is to NOT use floating IPs at all, only statically assigned, node-specific client facing IPs. This gives up the HA-aspect for the IPs but as described above, this will not work for multi-channel anyways.
Closing for the time being.
reopening as we're actively working on this. reassigning to Günther. Moving to 3.5.z
(In reply to Michael Adam from comment #5) > reopening as we're actively working on this. > reassigning to Günther. > Moving to 3.5.z Any updates?
(In reply to Yaniv Kaul from comment #6) > (In reply to Michael Adam from comment #5) > > reopening as we're actively working on this. > > reassigning to Günther. > > Moving to 3.5.z > > Any updates? Ping?
So what's the next step here? Do we continue and invest in this? Do we cease? What do we do with this RFE?
(In reply to Yaniv Kaul from comment #9) > So what's the next step here? > Do we continue and invest in this? Do we cease? What do we do with this RFE? The team as worked hard, apart from bugfixing and customer cases, to bring the SMB3 multi-channel feature to completion. And given the circumstances, the progress was not bad: There are 3 items: 1) Implementing oplock break retries after channel failure. ==> https://bugzilla.redhat.com/show_bug.cgi?id=1333325 This is almost done. 2) Implement fd-passing in socket-wrapper. This is needed for enabling selftest for multi-channel in the samba upstream CI/merge-gate. (I can't currently find the BZ for it, will look some more.) Progress here has also been good. Several prep steps are already merged, and final steps are in the process being made bug-free... 3) The clustering integration. (This BZ) This is the last item, and Günther has layed out the plan and first results above, but as mentioned #1 and #2 need to be completed first. It would really be sad to stop this effort now after the team has tried so hard and spent every (of the few) free minute(s) to bring this forward. Let's at least get #1 and #2 to completion, so that we move the feature out of experimental state in the upstream. Then we can re-assess the work needed to complete #3.
Status?
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days