Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
We want to support SMB3 multi-channel as described in [MS-SMB2] - https://msdn.microsoft.com/en-us/library/cc246482.aspx The core of the code is already upstream in samba 4.4 and master. see: * http://blog.obnox.de/demo-of-smb3-multi-channel-with-samba/ * https://wiki.samba.org/index.php/Samba3/SMB2#Multi_Channel * http://www.snia.org/sites/default/files/SDC15_presentations/smb/MichaelAdam_SMB3_Multi_Channel_%20rev.pdf We need to fix a few corner cases in upstream and harden it and integrate it into the product for downstream.
The basic functionality of multi-channel is already their in the latest build. Therefore moving this bug to ON_QA. All the bugs in the feature can be tracked separately.
Verified basic functionality of Multi-channel with single node samba server as follows: Positive workflows: 1.Verify if windows client discovers all the NIC's after setting the multi-channel option to yes. 2.Configure multiple NIC's of same speed (100mbps) on samba server,Verify that the I/O's are going on from all the NIC's. 3.Configure multiple NIC's of different speed 2(100mbps) 1 (1Gbps)on samba server,Verify that the I/O's are going on from the highest speed NIC. 4.Configure multiple NIC's and bring down NIC1 to verify that i/o continues to go on from rest of the NIC's. verified with multiple NIC down scenario. Multichannel with CTDB: ********************** When multichannel is configured with CTDB VIP , we see issues where if the NIC is brought down the ip-failover happens to the other node and there is a situation where one file is being accessed by two clients via different servers which may lead to data corruption.There are multiple issues opened to fix these problems: https://bugzilla.redhat.com/show_bug.cgi?id=1333325 https://bugzilla.redhat.com/show_bug.cgi?id=1333324 https://bugzilla.redhat.com/show_bug.cgi?id=1333326 After discussion several tests are done with configuring ctdb with static Ip and disabling public addresses. same tests are repeated, there is no faiover happening and the other node goes to banned state so that it should ban itself to access the file served by another server.so there is no data corruption. Once the NIC is up , ctdb node goes to banned state(BZ https://bugzilla.redhat.com/show_bug.cgi?id=1322677) Marking the RFE to verified. If other bugs will be found during testing will open another BZ. Also the doc has to be provided for setting up multichannel and its restrictions.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1248