Smb Direct – Smb3 Over Rdma
Key topics
The discussion ignited around SMB Direct, a feature that enables SMB3 to run over RDMA, sparking curiosity about its use cases, particularly in high-performance environments like AI model weight synchronization. Commenters shared their experiences, with some using Samba to load model weights from NAS, while others highlighted the performance benefits of SMB Direct, citing Microsoft's efforts to boost network storage performance. As the conversation unfolded, it became clear that SMB Direct is gaining traction, with Linux kernel support available from version 5.15+, making it accessible to non-Microsoft users. The thread revealed a mix of surprise, interest, and clarification around SMB Direct's capabilities and applications.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
5h
Peak period
18
Day 1
Avg / period
10
Based on 20 loaded comments
Key moments
- 01Story posted
Dec 18, 2025 at 8:42 PM EST
15 days ago
Step 01 - 02First comment
Dec 19, 2025 at 1:28 AM EST
5h after posting
Step 02 - 03Peak activity
18 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 27, 2025 at 7:45 PM EST
5d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I heard that it was perhaps recently fixed, but copying many small files was multiple times faster to do via something like Total Commander vs the built in File Explorer (large files goes equally fast).
People seeing how slow Explorer was to copy would probably presume that it was a lower level Windows issue if they had a predisposed bias against Microsoft/Windows.
My theory about Explorers sluggishness is that they added visual feedback to the copying process at some point, and for whatever reason that visual feedback is synchronous/slow (perhaps capped at the framerate, thus 60 files a second), whilst TC does updating in the background and just renderers status periodically whilst the copying thread(s) can run at full speed of what the OS is capable of under the hood.
[1] Finder has parts that show continued use of code written for MacOS 9 :V
A big, increasing over last decade, chunk of that is fear that they will break the compatibility - or otherwise drop in shared knowledge. To the point that the more critical parts the less anyone wants to touch them (heard that ntfs.sys is essentially untouchable these days, for example).
And various rules that used to be sacrosanct are no longer followed, like the "main" branch of Windows source repository having to always build cleanly every night (fun thing - Microsoft is one of the origins of nightly builds as a practice)
Less people are trusted to touch ntfs.sys due to lack of experience, thus they never gain it and that in turn means less work and in turn means even less people have proved themselves trustworthy enough to work on it.
Until nobody remains in the company that is trusted enough.
Microsoft gives them a lot of ammo. While, as I said, Microsoft et al. has seen that SMB is efficient, at the same time security has been neglected to the point of being farcical. You can see this in headlines as recent as last week: Microsoft is only now, in 2025, deprecating RC4 authentication, including for SMB.
MS would bend backwards to make sure those enterprise Windows 0.24 boxes will still be able to connect to networks because those run some 16bit drivers for CNC machines.
Meanwhile Google decided to kill a product the second whoever introduced it on stage walked off it.
Azure is a money-maked for MS, and wouldn't be so without those weird legacy enterprise deployments. The big question is if continuing to increase a posture about about security together with an "cloud" focus is actually in their best interest or if retaining those legacy enterprises would have been smarter.
I could see that or other safety checks making one program slower than another that doesn’t bother. Or that sort of thing being an opportunity for a poor implementation that slows everything down a bunch.
[0] https://www.usenix.org/conference/nsdi22/presentation/reda
[1] https://www.youtube.com/watch?v=sTT_XPfYudg
But with Apple's recent introduction of RDMA over Thunderbolt, that got my hopes up I could use it for storage, not only moving LLMs, but also for video file storage, where editing from one Mac to another (or over Ethernet, if that's supported) could be much faster, with lower latency.