Hello,
Is SMB over QUIC supported and or on the roadmap ?
Thanks and Best
This depends on readiness from upstream samba project. You can see their roadmaps online.
Yes I know since 4.23…
Ref. https://www.samba.org/samba/history/samba-4.23.0.html
My question was more focusing if Truenas will keep these extensions enabled or not…
Quite keen to test this out to see if it alleviates performance bottlenecks.
Background - this was me back in 2023:
https://www.truenas.com/community/threads/smb-performance-not-keeping-up-with-fast-nvme-drives.111940/
After considerable testing and attempts at tuning it turned out that the Windows client was entirely CPU bound on a single thread, which was a limit of the Windows 10 (and continuing on to Windows 11) TCP stack. That resulted in a maximum copy speed of somewhere around 12Gbit/s (~1.2GByte/s), give or take depending on the client’s maximum single threaded CPU performance (and writes being a little better than reads, also for TCP processing reasons).
macOS and Linux clients to the same share (and in the case of Linux, on the same workstation dual booting with Windows) had no such issue, as both OSes have a multi-threaded TCP stack, and could happily achieve double that performance. Tuning window sizes, hardware offloading of different things, etc made no difference to the Windows client, as it was always just the single-threaded TCP performance topping out. Multiple copies in parallel “worked”, however the workflow of this machine was specifically for streaming very large archive-quality raw media at high speeds via an application running on the Windows host, so “multiple parallel copies” wasn’t an option.
SMB-over-RDMA on Windows was considerably faster, however simply painful to configure, required specific RoCE capable NICs and switches, and would often silently fail and fall back to SMB-over-TCP without visible errors or warnings to the user (other than a notable speed decrease). Not at all a viable solution for this workflow. Nor am I a fan of SMB3’s multichannel offerings, which force you to have IPs in completely separate subnets for it to work, not to mention being frustrating when I’m getting less than 50% the performance out of a 25GbE NIC simply because of an OS limitation.
This week I’ve successfully tested Samba 4.23 running on a low end bare metal Arch Linux host with kernel 6.18 and the https://github.com/lxin/quic project to enable the quic.ko kernel module (recommended by the Samba 4.23 release notes). Connecting from a Windows 11 desktop client, everything worked as expected (UDP/443 traffic verified via tcpdump, as well as all other ports firewalled on the Samba server to ensure it was the case).
Once TLS certs are configured correctly and the transport enabled in the Samba conf file, even just hitting the UNC via FQDN works fine from a up-to-date Win11 client, as it attempts traditional SMB-over-TCP/445 first, then SMB-over-QUIC on UDP/443 second (although QUIC can also be forced by relevant net use and New-SmbMapping style commands if you want to present both protocols but force QUIC for certain machines, and likewise TLS certificate validation can be ignored if you want to test with self-signed certs).
SMB-over-QUIC is marketed by Microsoft as “SMB VPN”, more as a way to get SMB access to Azure/cloud instances over an internet-friendly QUIC UDP/443 (used by HTTP/3). However that’s not my interest at all - I’m far more interested to see if this alleviates the slow-as-mud Windows TCP stack problems, and finally lets me get past a problem that really shouldn’t exist any more (and doesn’t exist for literally every other non-Windows client OS).
Hoping to be able to re-test all of this on some higher end gear soon to see how it performs. But with any luck, this is the end of using nonsense workarounds for a very tedious Windows performance problem.
1 Like