KSMBD Declared Stable - No Longer "Experimental" - In Linux 6.6

[S.Pam]

Let's see. Got the CS degree. Built filesystems both in Kernel and in user space (ok on Windows, so probably don't count) Pretty sure my question is why Windows no longer runs SMB in kernel space, you know... after half the world was screwed over by a SMB vulnerability in the early 2000s.



No - you have a big character flaw... And you don't know the answer, otherwise you'd write it (probably saying something semi-accurate like having access to the filesystem cache in kernel space). And I'd still point out that user space is fast enough for SMB in Windows, coz the bottleneck is the network card...

Good points. Another point is that if a kernel module fails it can bring down the kernel, or at least severely cripple the system. This, in fact, is what happens with Linux TCM/LIO (targetcli). We've been using it for years as iSCSI target at work on various types of servers. Every now and then it will crash because of 'something', and only way to remedy the situation is to forcebly restart the server, because the iscsi module is holding some lock that can't be broken. After some years we now discovered the user-space tgt iscsi server, and it has been flawless. Performance is easily on-par, because as you say, network itself is the bottleneck.

https://github.com/fujita/tgt

[OneTimeShot]

Get a CS degree (because the fundamentals are important), a few years developing software larger than hobby projects (NOT web sites), and figure out why in kernel filesystems are always better performing than FUSE then you might figure out why widely used network filesystems should have a kernel component.

Let's see. Got the CS degree. Built filesystems both in Kernel and in user space (ok on Windows, so probably don't count) Pretty sure my question is why Windows no longer runs SMB in kernel space, you know... after half the world was screwed over by a SMB vulnerability in the early 2000s.

Yes, I'm acting grumpy.

No - you have a big character flaw... And you don't know the answer, otherwise you'd write it (probably saying something semi-accurate like having access to the filesystem cache in kernel space). And I'd still point out that user space is fast enough for SMB in Windows, coz the bottleneck is the network card...

[ClosedSource]

When you pull in a couple billion dollars a year, hire a few kernel developers for your agenda, then you can set priorities for work. Otherwise, unless you're actively contributing to a project, no one much cares what some rando on the Internet thinks.

I understand that pretty much anything I voice here is useless and nothing more than an pointless and annoying rant. However, I have on several occasions relayed my rants to connections at Microsoft, NVIDIA, and several others. It's not like I'm hiding behind the internet. I just feel that a lot of this should be downstream only till not experimental anymore. At the very least, don't upstream it till it has less than a year left before it is marked non-experimental. And I don't develop websites

[elvis]

Id like to see some benchmarks of samba vs ksmb

I've been doing this for the last month or so now. I have a customer who needs some fairly hefty single-client performance over SMB, and the difference ksmbd made over Samba was enough to warrant the effort.

There are bigger problems on the client side currently. They're using Windows client-side, which has some severe performance issues with SMB over TCP. This is rectified by moving to SMB over RDMA (aka "SMBDirect"), however that has a host of other technical issues that come into play.

With Linux as a client using the standard mount.cifs tools, performance over TCP is far better, and the difference between ksmbd and Samba are noticeable enough to matter for their use case.

If you're serving Excel spreadsheets to corporate drones, then no, it's not going to matter to you. Unfortunately most of the best-practice and tuning guides for SMB at scale are for this scenario, and not for a handful of high performance clients sharing large centralised storage over Ethernet (25GbE or higher). Likewise recommendations for large scale clustered storage satisfy the "many-to-many" problem, but still don't achieve the single-client throughput required for this use case.

(Also, I'm tired of vendors asking if I have jumbo frames and RSS enabled - yes, we did the basics. Yes, performance under Windows still sucks).

[timofonic]

Is the sky really falling? Or just in your own world?

Do I need to say it was pure sarcasm?

[NotMine999]

Oh, yes. Fscking corpos and their GPL eroticism!

We all know corporations really love GPL, they are relicencing everything to GPL, even Microsoft will relicense Windows 12 entirely in GPL. The same about Apple, Sony, Nintendo, Autodesk, Adobe and everything else.

The GPL plague is destroying the world! It's ceating a monoculture! Everything is becoming GPL! Why do they don't use something more sane and healthy such as BSD?

Is the sky really falling? Or just in your own world?

[timofonic]

This is horrible attitude. Just because something happens to be unfortunately GPL licensed doesn't mean it's Ok for everyone to shove their corporate agenda into it.

Oh, yes. Fscking corpos and their GPL eroticism!

We all know corporations really love GPL, they are relicencing everything to GPL, even Microsoft will relicense Windows 12 entirely in GPL. The same about Apple, Sony, Nintendo, Autodesk, Adobe and everything else.

The GPL plague is destroying the world! It's ceating a monoculture! Everything is becoming GPL! Why do they don't use something more sane and healthy such as BSD?

[avis]

Linux is the absolute opposite of a microkernel. Not only from a technical standpoint, but also from a philosophical standpoint. Features, which have not to be implemented in the kernel, are getting implemented in the kernel. This is absolutely unnecessary!

Blacklist the module (or don't enable and build it like I do), sleep well.

[stormcrow]

This is horrible attitude. Just because something happens to be unfortunately GPL licensed doesn't mean it's Ok for everyone to shove their corporate agenda into it.

When you pull in a couple billion dollars a year, hire a few kernel developers for your agenda, then you can set priorities for work. Otherwise, unless you're actively contributing to a project, no one much cares what some rando on the Internet thinks.

Dunno - unless your network card is stupidly fast, and your CPU is useless, I don't see why this can't be done in userspace.

Get a CS degree (because the fundamentals are important), a few years developing software larger than hobby projects (NOT web sites), and figure out why in kernel filesystems are always better performing than FUSE then you might figure out why widely used network filesystems should have a kernel component.

Yes, I'm acting grumpy. I'm just irritated at all the entitled nonsense I keep repeatedly seeing in Phoronix, usually from the same people over and over. It's as if one person's use case is the only one that matters. Don't mistake your personal use as a majority, or even a sizeable minority. The vast majority of Linux users aren't individual desktop users. They're 1) mobile users using some usually corporate sponsored fork of AOSP with proprietary apps on top, 2) corporate servers, or 3) IoT products & deployments (including set top boxes and the occasional gaming device). Traditional Desktop Linux is only a tiny fraction of the amount of Linux systems in active use and most of those are developers and IT staff working on 1 through 3.

All of those corporations are funding development, so it shouldn't be surprising that corporate interests in those spaces are getting priorities when it comes to features. However, in this case KSMBD is not just a corporate oriented project. It's ultimately meant to supplement one of the more common uses for Linux and likely replace the antiquated CIFS drivers, both for SOHO and enterprise: Samba based file shares.

I'm personally of the opinion that special cases should always live outside the mainstream kernel, and the mainstream kernel should have more stable APIs to build against. FreeBSD does this extremely well, after all. But this is one of those cases where people that understand how OS kernels filesystems work, even a little bit, should be thinking more "Hmmmm... let's dig..." rather than "OMFG CORPOS ARE KILLIN MY LINUCKS!!!!11111". Of all people Steven French knows exactly what he's doing in this space since he's been working on CIFS and its Linux kernel driver since 2002 and SMB v.3 since 2012.

[OneTimeShot]

Dunno - unless your network card is stupidly fast, and your CPU is useless, I don't see why this can't be done in userspace.