Not really related to this thread so a new thread would be better on followup questions. Anyhow, it can be done but it naturally has some caveats and it won't get any real support here or in other support channels on issues and you're rather on your own so to say. As the kernel is rather independent of any userspace tooling, besids ABI/Feature support (which normally limits one more in how far one can go back), and we often test some bugs/features in mainline kernel build ourself - I'd personally not use them in production though.
5.17 isn't even released upstream and still on RC5, so I'd only go for that if everything else fails.
Also, SMB3 multichannel support was initially added in the 5.5 Kernel (
ref) with some subsequent big improvements landing in the 5.8 kernel, so, that feature is already included in current default 5.13 kernel or the newer, still opt-in 5.15 kernel; the 5.17 one only saw only some minor improvements regarding reconnects and code restructuring, so why'd you need an not yet release, still under development and heavily experimental build for that??
https://wiki.samba.org/index.php/SMB3_kernel_status#Multi_Channel
maybe, maybe not, depends a lot on your environment and actual HW/setup, nobody can give you guarantees for an not even released kernel.
First, thanks for responding to me.
About the question: "so why'd you need an not yet release, still under development and heavily experimental build for that??"
Here's my answer: I've been testing kernels and configurations for a week for my environment to work with SMB3 multichannel. I tested with kernels 5.13 (from proxmox), 5.15 (from proxmox), 5.10 (debian stable ). 5.14 (debian backports), 5.15 (debian backports) and 5.17 (debian experimental). Only kernel 5.10 and 5.17 worked in my specific scenario multipath SMB3. I came to suspect that it was something compiled in the 5.13 and 5.15 kernel of proxmox, so I installed the 5.15 kernel (debian backports) and the multipath also didn't work anymore, leading me to the conclusion that something was changed in the source code by the developers that caused some problem for the functionality (my interfaces scenario without bond or lacp). My suspicion was confirmed when I searched the samba community and found the notification that more than 50 changes were made to the code (even it was all redone) for the SMB3 multipatch mechanism in this 5.17 kernel. And it was exactly the 5.17 kernel that worked SMB3 multichannel. I spent almost a week testing and trying to understand the reason and believe me, only 5.17 and 5.10 is that multipath works correctly (true distribution equals multipath iscsi). So this is why I'm looking for the 5.17 kernel. If I stick with the 5.10 kernel, it's not native to proxmox 7.1.2, that's why I asked about the situation of installing a kernel from debian's stable repository. The problem is with the CIFS module built into the kernel (version 2.35 is the module that adds the feature and has had many fixes in kernel version 5.17). On 5.13/5.15 kernels the cifs.ko module is still version 2.33/2.34 (with bugs that prevent multichannel in my scenario or have bugs that don't let the feature work properly).
I think multichannel SMB3 and pNFS will be a great option for those who need efficient load-balanced connections using only layer 3+4 (no need to use LACP or bond on the interfaces). So I'm focusing on this solution.
If you participate in the review of the 5.17 kernel to officially put in the future on proxmox, I recommend keeping an eye on this kernel to be made available as soon as possible, as this is the key to excellent performance distributing bandwidth without the need for LACP/Bond using just an SMB3 folder with multichannel capability and it will probably be a much better solution than LVM+iSCSI, because in addition to CIFS having better management in simultaneous accesses on competing clients, it will have maximum speed equally distributed on each network cable without need configuration in switch, just using the command "mount -t cifs -o multichannel" in a folder and putting proxmox in each client. Not to mention that it still allows the feature of multiple snapshots using the qcow2 format. A much better scenario than LVM+iSCSI and much simpler.
On the issue of multichannel working on kernels from 5.5 onwards: There is a difference between releasing a feature and it being permanently functional throughout additions of functions in the code and saying that it is compatible with the feature. The feature can work with a windows client to a samba server (it will work just fine). But the scenario here is a unique module in the kernel on the client side which is not used on the windows client. The cifs.ko module is a separate part of the resource and is used on the linux client side, it is precisely this module that is being matured and it only worked in version 5.10 (there was some code that worked well) and 5.17 (they added a fix that made the code).
The samba community article reporting the CIFS module scenario "
"[5.17 kernel (module version 2.35, 50 changesets so far)]: ...Reconnect improvements for DFS and multichannel use cases, and restructuring of multichannel code. Fixes to serialize mount attempts to avoid races, to fix memory leak during ntlmssp negotiate , and to DFS special character handling, and also important ACL fixes and fix for snapshots post conversion to the new mount API (in 5.11)..."
Source:
https://wiki.samba.org/index.php/LinuxCIFSKernel
Anyway, thanks for the information posted. My alternative will be to keep the 5.17 kernel to guarantee the feature and keep an eye on the test environment until the community releases this kernel permanently on proxmox or debian stable.
