Samsung Posts Newest "KSMBD" Linux Patches For In-Kernel SMB3 Server

[phoronix]

Phoronix: Samsung Posts Newest "KSMBD" Linux Patches For In-Kernel SMB3 Server

For quite a while now Samsung engineers have been developing an in-kernel SMB3 file sharing server for the Linux kernel. In recent months that code has been maturing more and now the latest version of this KSMBD kernel code has been published...

https://www.phoronix.com/scan.php?page=news_item&px=KSMBD-In-Kernel-SMB3-v5

[flower]

tbh i still don't understand why this is necessary.
if there are some features missing which forbis developing this as good in userspace this is what needs to be fixed.

[jrch2k8]

tbh i still don't understand why this is necessary.
if there are some features missing which forbis developing this as good in userspace this is what needs to be fixed.

This has nothing to do with missing features, basically is about performance also don't think of this as Samba on the kernel because is not but more like NFS works, which means Samba could use it eventually as well.

To put it simply is faster because is closer to the metal, lot less context switches and can use internal kernel infrastructure that is way more efficient like RDMA, kernel side allocation(for this kind of thing is as good as it gets), buffer sharing or zero copy directly against the kernel raw network stack, direct CPU feature access(like in kernel aesni, etc.), etc, etc.

Please note NFS is on the kernel for the same reasons, for example.

Why not expose everything to userspace? first of all because it will be a security nightmare and second it will murder any performance benefit.

For example (very very simplified just to paint a picture and yes i know is not exactly 100% accurate, again trying to keep it simple) :

1.) The kernel can request memory pages directly to VMM and lock them for exclusive use, hence the module only has to interact with 1 layer (VMM) but user space cannot for obvious security reason which is why allocate memory on user space is expensive (lot more layers and context switches to reach VMM) which is why since forever we have tools to optimize this stuff regardless of the OS.

2.) The kernel can allocate directly(as with a lot less layers in between) to special memory devices(like some hardcore server NIC buffers).

3.) Way faster access to filesystems through VFS directly or access special in-kernel only features of specific filesystems meanwhile filesystems can also add in-kernel only optimizations for SMB3, NFS, etc.

[flower]

To put it simply is faster because is closer to the metal, lot less context switches and can use internal kernel infrastructure that is way more efficient like RDMA, kernel side allocation(for this kind of thing is as good as it gets), buffer sharing or zero copy directly against the kernel raw network stack, direct CPU feature access(like in kernel aesni, etc.), etc, etc.

now lets just implement some rdbms or mail servers in kernel space too? why even have that seperation? lets just run games in kernel space too - its faster.

there is a reason why user and kernel space is seperated. the reason is security.

[ferry]

If it's just for performance, then it would be good if they would have feature parity and a shared code base.

[MadCatX]

I wonder what kind of performance are these guys targeting that they need to dump an entire network file sharing subsystem into the kernel. It sounds like a huge security liability with dubious benefits. I remember when KDBus was a thing and performance was one of the reasons why it had to be in the kernel, only to turn out that a more efficient userspace implementation can fix the performance issues too so now we have dbus-broker. I wonder if this is a similar case.

[zexelon]

Why stop here? I am looking forward to in kernel wayland compositor, paired with an entirely in kernel desktop environment too!! This is totally awesome we could completely do away with the "ringed privilege's" system and return to the 8080; everything running on bare metal... who want context switches anyway?

Oh wait...

[jrch2k8]

I wonder what kind of performance are these guys targeting that they need to dump an entire network file sharing subsystem into the kernel. It sounds like a huge security liability with dubious benefits. I remember when KDBus was a thing and performance was one of the reasons why it had to be in the kernel, only to turn out that a more efficient userspace implementation can fix the performance issues too so now we have dbus-broker. I wonder if this is a similar case.

DBUS-Broker and KDBUS(BUS1) functionality don't fully overlap but it is way better than the old implementation on user space but i wouldn't go as far as to make claims of performance vs since there is no reliable data in that case

[jrch2k8]

now lets just implement some rdbms or mail servers in kernel space too? why even have that seperation? lets just run games in kernel space too - its faster.

there is a reason why user and kernel space is seperated. the reason is security.

Do you understand SMB is a network protocol not a service/daemon/process/executable/library/game/application/etc.???

Samba and Microsoft implementations are SMB/CIFS aka the network protocol PLUSall the extra infrastructure(LDAP, DNS, User management, Security, Logon, etc.) and as far i can tell they are working in conjunction with samba and is also pretty nicely explained in the FUCKING PATCH

Some Quotes:

"ksmbd is a new kernel module which implements the server-side of the SMB3 protocol"

"The Samba project is much broader in scope (tools, security services, LDAP, Active Directory Domain Controller, and a cross platform file server for a wider variety of purposes)"

"This is not meant to replace Samba, but rather be an extension to allow better optimizing for Linux, and will continue to integrate well with Samba user space tools and libraries where appropriate."

"Working with the Samba team we have already made sure that the configuration files and xattrs are in a compatible format between the kernel and user space serve"

I just take comfort no one that matter in decent projects take into consideration post like this to make engineering decisions, Jesus

[microcode]

tbh i still don't understand why this is necessary.
if there are some features missing which forbis developing this as good in userspace this is what needs to be fixed.

The filesystem drivers are in the kernel, and so are the network drivers, so putting the network filesystem server (whether it's SMB or NFS) in the kernel can resolve some issues with performance. Granted I think you could probably get similar performance with io_uring nowadays, with maybe slightly worse latency.