Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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?pa...Kernel-SMB3-v5

  • #2
    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.

    Comment


    • #3
      Originally posted by flower View Post
      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.

      Comment


      • #4
        Originally posted by jrch2k8 View Post

        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.

        Comment


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

          Comment


          • #6
            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.

            Comment


            • #7
              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...

              Comment


              • #8
                Originally posted by MadCatX View Post
                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

                Comment


                • #9
                  I see a company that needs a feature implemented kernel-side that kindly contributed back to the community with an optional and modular piece of code, just like FOSS dictates. I’m pretty sure plenty of NAS owners and NAS-centric distro maintainers will be oh so happy about a mega-company doing the R&D for them so they can benefit from a more performing SMB server FOR FREE.

                  Comment


                  • #10
                    Originally posted by flower View Post

                    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

                    Comment

                    Working...
                    X