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

[jrch2k8]

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.

mmm, io_uring could help on certain I/O scenarios like non blocking read write requests on SSDs but won't be much help with the other operations on the protocol and using hardware acceleration features more directly(as NIC's silicon features for example) also will not help if in the future filesystems want to implement special handling for ksmb3 like for example inode write queue prioritization to help keeping an more predictable write speed on certain devices(like server grade NVME 2.0 devices), etc.

CAVEAT: I haven't really read the whole patchset hence i cannot say for sure is not using io_uring internally already where it makes sense

[mangeek]

I don't have skin in this game, nor am I an expert in this area, but I was sort of hoping that Linux would evolve in the opposite direction. It is what it is, though; Linux isn't a microkernel.

[pal666]

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.

now lets just implement some ext4 or btrfs in userspace too?

[jrch2k8]

I don't have skin in this game, nor am I an expert in this area, but I was sort of hoping that Linux would evolve in the opposite direction. It is what it is, though; Linux isn't a microkernel.

believe it or not is the right direction, please stop associating adding or removing stuff with efficiency because that is not how it works.

The Kernel first have literally thousands of modules already that no regular X86 pc will ever use and yet their effect on its efficiency and performance is 0 because the kernel only loads(or execute) what it requires when is required anything else is just few kb on your drive that will never use any resource(Ram/CPU/GPU/Networks, etc.) ever and if you feel the need to save those couple of extra megabytes on disk you can instruct the kernel to only compile code your machine will use(very smart build system).

Second the kernel is the place where you want network protocols to live(regardless of the design philosophy) and SMB is a network protocol, NFS is a network protocol, Netware is a network protocol, Wireguard is a network protocol(that in conjunction with other tools on user space becomes a VPN service), etc.

And like with all the aforementioned examples ksmb3 requires tools and service to operate that will reside in user space(like samba) and without those explicitly requiring this module it won't be loaded at all in the same sense your kernel right now is not auto loading NFS and randomly transmitting files on its own into the air, hence adding ksmb3 to the kernel have absolutely 0 impact until you actually and explicitly require to use it.

I understand that people that come from Windows will fear that anything new will affect their system because it usually it install a ton of crap that runs on the background and starts adding up but that is not how linux kernel works or decides to handle resources.

[hoohoo]

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.

I do understand your point. This kind of change is a bit ironic. Back in the day Netware was all ring zero all time, and it was a stability nightmare.

[hoohoo]

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

And if you could be more polite the world would be a better place.

SMB is a file sharing network protocol, it is much bigger than, say, TCP. And it is a protocol with a considerable history of security holes. People have a right to be concerned.

Oh, and keep your vitriol to yourself. I am not interested in it.

[arQon]

A company I worked for several years ago sold underpowered NAS's, and as a result had to optimise Samba and a few pieces of the kernel (which we did, and contributed back per GPL) to get those very weak boxes to be able to sustain GbE with basically no RAM and washing machine grade CPUs. But they managed it eventually.

So, no: I don't buy the (mouth-frothing) "but, performance!" drivel in some of these posts, at all. Compared to even a low-end PC, you would need *at least* 10GbE connections for this to matter at all, and even that would just be background noise on a proper workstation or server. It obviously makes sense to Samsung (though I have no idea if that's because they're working from a bad starting point or not), but it doesn't make any sense to me.

Meanwhile, they don't even have SMB3 multi-channel working: so ANY claims of performance benefits *at this time* are absolute bullshit, period.

SMB is not the world's most well-designed protocol, to put it kindly, and while 32K lines isn't "a lot of" code, it's certainly a lot MORE code than can sanely be vetted. Randomly throwing giant piles of crap into the kernel without any real reason for it is how you turn a userspace problem into a kernelspace one, and the negative repercussions of that should be obvious to anyone.

So this is a bad idea in general, unnecessary in practice, and currently not even fit for purpose. Anyone supporting it in this current state is doing an awful lot of wishful thinking.

[MadeUpName]

Keep in mind this is likely targeted at the hyper scalers where this would make sense.

[jrch2k8]

1.) So, no: I don't buy the (mouth-frothing) "but, performance!" drivel in some of these posts, at all. Compared to even a low-end PC, you would need *at least* 10GbE connections for this to matter at all, and even that would just be background noise on a proper workstation or server. It obviously makes sense to Samsung (though I have no idea if that's because they're working from a bad starting point or not), but it doesn't make any sense to me.

2.) Meanwhile, they don't even have SMB3 multi-channel working: so ANY claims of performance benefits *at this time* are absolute bullshit, period.

3.) SMB is not the world's most well-designed protocol, to put it kindly, and while 32K lines isn't "a lot of" code, it's certainly a lot MORE code than can sanely be vetted. Randomly throwing giant piles of crap into the kernel without any real reason for it is how you turn a userspace problem into a kernelspace one, and the negative repercussions of that should be obvious to anyone.

4.) So this is a bad idea in general, unnecessary in practice, and currently not even fit for purpose. Anyone supporting it in this current state is doing an awful lot of wishful thinking.

1.) I agree with you on the fact this is not for your 486DX 100M lan server and once is finalized even with multi-channel support it will not show much performance gains outside lower latency.

This is meant for EPYC/Xeon/Mellanox/NVME2+ systems that are meant to handle 10k+ workstations enterprises that generate thousand of medium to small files with very high frequency, for your regular office Samba IPC brute force will do the job just fine.(aka Goverment, Huge enterprise like Samsung,etc.)

2.) You are assuming they will land in this kernel, this will probably land on 5.18+ after few more revisions maybe by then all the feature will be on good enough shape(follow the patch timeline and you will see every post have more features than the last)

3.) I've never seen a well designed protocol(they all make sacrifices, that is engineering) and honestly 32k LoC is on the small/medium side.

Network subsystem in the kernel is pretty well isolated and 32k LoC or 50m LoC will make no difference to the kernel since nothing in that subsystem get loaded without user space tooling, if this lands or doesn't will make no difference for anybody except those that will explicitly use it.

4.) just nope here to the whole line and no one is supporting anything yet since this is basically another RFC, once it hits staging(assuming it lands) then people can test and make an informed decision

[jrch2k8]

And if you could be more polite the world would be a better place.

People have a right to be concerned.

Oh, and keep your vitriol to yourself. I am not interested in it.

I will be as polite or impolite as i determine necessary in the context of the situation, you are free to skip any post you consider "impolite".

One thing is being concerned and other thing is spreading FUD without even bother to read the patch or even have a rudimentary understanding on how the kernel subsystems work first and no only the kernel team and Samsung(in this case) have "rights" in this context since "people" are not contributing anything and 99% of the posts here show clearly they have absolutely no idea how any of this work at any level, what the code actually does, the quality of the code, etc.

I will not keep anything to myself unless i determine so myself and i really don't care if you are interested in it or not(and please take the meaning of care to its widest interpretation because i doubt you have meet anyone that care as little as i do)

P.D last reply since i have no interest in expanding this line of conversation any further and i think this was explicit enough.