Back in 2021 Samsung engineers posted KSMBD as an in-kernel SMB3 server alternative to the likes of the user-space Samba server. KSMBD merged into Linux 5.15 as an experimental SMB server while after two years of fixes and other improvements has now dropped its “experimental” marking.
The KSMBD in-kernel SMB3 server is now formally declared stable with Linux 6.6 in removing its experimental tag.
Neat.
Hopefully, it will be backported into the 5.14 kernel (RHEL9)
What does everyone thing about daemons being implemented as kernel modules rather than userspace processes? Is this something to be encouraged in general?
After all, just about every daemon we have in user-space could be implemented as a kernel function instead, so where should the line get drawn?. What about a database, web server, telnet/ssh, a redis-like caching daemon?
I actually think there might be be merit for a special in-kernel caching mechanism. Not only does that need to be fast, but it also solves some of the OOM issues by giving the kernel the option to free cache data rather than killing applications. It seems appropriate for a kernel to handle caching. But I am skeptical of more complex daemons that implement network protocols, These create new attack surfaces and it’s less clear to me that the cons are justified by the pros.
GPL2 would typically be the case but for example DRM stuff for graphics is dual licensed MIT/GPL.
But generally I am against this… kernel should be managing resources, not providing services directly.
cb88,
I looked at KSMBD sources and they only specify GPL2.
I should really give it a spin myself, but that’s my initial gut feeling as well. It’s funny to allow features like this into the kernel when Torvalds has stated that linux is too bloated. This is exactly the kind of extra features that make the kernel source tree so bloated. Meanwhile distros are still going to have to support Samba since KSMBD is unlikely to ever reach feature parity.
It is a good question. My first reaction was “why is this in the kernel?”. My next thought was, “wait, isn’t there an NFS server in the kernel already” and indeed there is. So, this is nothing new.
The motivation for kernel modules vs userspace is the same as monolithic kernels vs micro-kernels. So we can dig-up the Linus vs Tannenbaum debate if we want to run through that argument again.
Just because a module exists though does not mean that it has to be loaded. In that way, modules do not really bloat the kernel. If I do not use this, my kernel is no bigger or slower than it was. More kernel complexity is a valid complaint but a small one really as we already have a module architecture and, when this module is not loaded, the remaining kernel does not really contain any latent complexity that is specific to this module. A similar argument could be made for maintenance as most of the maintenance burden will go to this modules sponsors. If it is not maintained, it will get removed. There is a certain amount of oversight overhead on the kernel maintainers of course though as you say.
The motivation is clearly performance ( as you more or less outline ). The cons you mention mostly only impact people that use this module and are choices that the end user can make. I imagine that SAMBA will continue to exist. So, while I might hope my distribution does not enable this module by default, a more Enterprise user may be extremely happy to see this change. Linux is a big tent.
What do you mean when you say “much less portable”? I do not get that. How does moving from user-space to the kernel make the code less portable? Obviously, it was only running on architectures where the kernel was running before. Or do you mean that the implementation becomes more Linux specific ( eg. this SMB server is not going to be running on FreeBSD )? If that is what you mean, I agree. Again, I expect that SAMBA will continue to exist but I suppose this could steal a lot of its popularity and impact the viability of that project negatively.
Your list of pros and cons is good. Mostly userspace daemons will not want to run in kernel-space unless the performance advantage really matters ( which it does not for many things ). So, this does not necessarily signal a rush to move everything into the kernel. As I said in my opening paragraph, there is really nothing new here. We have had “servers” in the kernel for a very, very long time.
Let’s just keep systemd out of the kernel. 🙂
tanishaj,
I went back to Linus’s comments to see exactly what he had said of linux bloat…I didn’t remember if we has talking only about runtime bloat or source code bloat. I got the impression it was both but he wasn’t very specific though…
https://www.theregister.com/2009/09/22/linus_torvalds_linux_bloated_huge/
It’s the later. I didn’t mean architectural portability, but rather operating system portability. Unix userspace software are broadly compatible without many changes thanks to POSIX standards and long term stable userspace APIs. Linux kernel drivers don’t have a stable API, much less a portable one.
More daemons moving into the linux kernel (hypothetically) would place other operating systems like BSD in a worse position in terms of reusing source code from those projects. A lot more linuxisms would be present and patches to compensate for the routine linux API breakages would be needed.
Will be interesting see how things work once Samba integrates support for KSMBD, and what the differences are between using the kernel daemon vs the user-space daemon.
phoenix,
Without studying the code, it’s hard to know if the feature differences will allow for samba to use KSMBD, I don’t know how much is hard coded by the kernel driver such that samba couldn’t use it.
Before even discussing whether samba should switch anything out, we should be asking whether the performance gains even make it work it. And to this end, the performance benchmarks are, well, interesting…
The ksmbd github readme shows fair gains over samba…
https://github.com/namjaejeon/ksmbd#performance
However it does not look like the enabled the latest and greatest io_ring performance enhancements in samba, which when enabled beats the pants right off of ksmbd…
https://samba.plus/blog/detail/ksmbd-a-new-in-kernel-smb-server
So with that in mind, it seems that if you want both the fasted server by a wide margin and most features, samba is the winner on both counts. (Please link if anyone knows of newer benchmarks!)
Work is already happening to add io_uring to ksmbd. A while back a package update broke samba so on a whim I decided to try ksmbd. It’s worked well for my use-case, with any bumps quickly fixed. I’ve been using/testing it with both Linux and Windows clients. I haven’t noticed any negative impact of using ksmbd. No, ksmbd is not going to bloat or slow down your kernel, and no it isn’t going to gobble your resources. I don’t take issue with ksmbd any more than I do with the kernel nfs server, which I’ve been using for ages.
Samba project already has plans to integrate KSMBD. Or, I should say, there’s work underway between the two projects to allow the Samba userland tools to be used with the KSMBD daemon.
https://samba.plus/blog/announcements
Search for ksmbd on that page.
phoenix,
Ok. I see it. I wonder if, when the work is done, the two will be at feature parity or the feature gap will remain because the kernel driver isn’t flexible enough.
Anyway, while I do run samba on my network, I doubt there’s going to be much of an advantage for me. I use NAS for backups and archiving but not high performance applications, so my NAS bottleneck will surely be the physical disks. I would try it out of curiosity though.
Being quite ignorant of what should or should not go into the kernel, this raises some concerns for me as an end user, and one time admin.
The first being security. Having any higher level network protocol directly in the kernel just sounds scary. How many Samba security issues have come out over the years? Or HTTP, NFS, etc.
If something is found, you’re not just updating the Samba package. Now you’ve got to update the kernel. Most distros are pretty slow about kernel updates. Even outside of security issues, who knows what other bugs may be found that don’t make it into security updates for the kernel, but would be in a packaged service.
I would also be concerned about support for the protocol outside the Linux realm. BSDs and Macs come to mind immediately.
I suppose the performance increase must be substantial to have put the work into this in the first place. I just wonder if the trade-offs are going to be worth it.
Metrol,
…or KSMBD…
https://access.redhat.com/solutions/6991749
Obviously they’ll fix known vulnerabilities as usual, but I agree this clearly increases the kernel’s attack surface. This is the polar opposite of microkernels, where the idea is that components are isolated for security and robustness.
Yeah, I alluded to this in my post as well. Daemons in the kernel are much less useful outside of linux, especially without a stable API that can be ported to other kernels.
I posted this above already, but as of right now samba’s asynchronous implementation appears to be faster.
https://samba.plus/blog/detail/ksmbd-a-new-in-kernel-smb-server
Obviously every optimization in userspace can be copied to kernel space so this might be implemented for KSMBD at some point as friedchicken mentioned. But in practice I don’t think samba/KSMBD are going to be the primary bottlenecks anyways when a midrange CPU from 4 years ago can handle 14-35GB/s. So while it’s well and good that KSMBD might (eventually) be able to top out a couple GB/s higher in synthetic benchmarks, most real deployments will never reach those theoretical speeds anyways.
So in summary, I’d say KSMBD performance is a con today, which may turn into a pro tomorrow, but either way it’s of limited importance like a sports car that tops out of 150MPH versus 200MPH. Are you actually going to appreciate the added speed or is it just for bragging rights? If anything, I am more curious about the energy efficiency under realistic speeds. Maybe KSMBD could win there? I don’t really know how much energy it costs daemons like samba to traverse the userspace barrier, somebody needs to test this 🙂