Bug 15115 - Multichannel channel failing causes server to get wedged for remaining channels
Summary: Multichannel channel failing causes server to get wedged for remaining channels
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.15.6
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Stefan Metzmacher
QA Contact: Samba QA Contact
Depends on:
Reported: 2022-07-01 23:32 UTC by suinn
Modified: 2022-07-22 00:15 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description suinn 2022-07-01 23:32:29 UTC
In earlier versions of Samba when multichannel was still experimental, a channel fail during writes would cause a 10 second delay before the remaining channels would continue to respond.

In latest Samba with official multichannel support, now the server just gets wedged and the remaining channels stop responding forever.

QNAP TVS-x72XT, 4GB RAM, Four Samsung 860 EVO 1 TB drive as RAID0, Firmware, SMB Server 8 MB max IO. 

Steps To Reproduce:
1. Connect to server and establish 2+ channels
2. Start a file transfer to the server (ie constant Writes)
3. While the writes are occurring, pull ethernet cable out or pull Ethernet dongle out of client computer.

In earlier Samba, the other remaining channels would stall for around 10 seconds and then the server would start responding on those channels.  With Version 4.15.6, the server just stops responding on all channels forever.

Expected Results:
Remaining channels should continue to respond without any delays when another channel goes down.  If you do a Read test, then the server works just fine in this manner.

In the attached packet trace at 2013763, one channel is disabled and you can see the 10 second delay before the remaining channel continues to respond.  In new Samba, all channels just stop responding forever.
Comment 1 suinn 2022-07-01 23:35:05 UTC
Well, bugzilla crashes when I upload the 1.59 GB packet trace, so no trace for you.
Comment 2 Jeremy Allison 2022-07-02 01:20:08 UTC
One for metze to comment on I think.