Announcement

Collapse
No announcement yet.

CIFSD In-Kernel SMB3 File-Sharing Server Lands In Linux-Next

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

  • CIFSD In-Kernel SMB3 File-Sharing Server Lands In Linux-Next

    Phoronix: CIFSD In-Kernel SMB3 File-Sharing Server Lands In Linux-Next

    Samsung for some time now has been working on an in-kernel SMB3 protocol implementation for file sharing across the network with "CIFSD" and it's now been queued into Linux-Next meaning it will likely go for mainline in a coming cycle...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    It sounds pretty crazy to me that a kernel is to have a in-kernel file sharing server.

    Comment


    • #3
      Originally posted by uid313 View Post
      It sounds pretty crazy to me that a kernel is to have a in-kernel file sharing server.
      what about nfs?


      but well you are right. a microkernel would be nice to have

      Comment


      • #4
        +The subset of performance related operations belong in kernelspace and
        +the other subset which belong to operations which are not really related with
        +performance in userspace. So, DCE/RPC management that has historically resulted
        +into number of buffer overflow issues and dangerous security bugs and user
        +account management are implemented in user space as ksmbd.mountd.
        +File operations that are related with performance (open/read/write/close etc.)
        +in kernel space (ksmbd).
        It's hard to debate this without benches to back it up, but I can only assume they saw significant benefits. The onus is on them to justify it either way.

        In any case, Samba isn't going anywhere, so whether this succeeds or flops is ultimately moot. But it doesn't seem too unreasonable.

        Comment


        • #5
          I would like to know what advantages gives cifsd versus nfsd...If we already have a kind solution, why adding another one? I ask from own ignorance. Thanks!

          Comment


          • #6
            Originally posted by q2dg View Post
            I would like to know what advantages gives cifsd versus nfsd...If we already have a kind solution, why adding another one? I ask from own ignorance. Thanks!
            When you need to access a windows machine.

            Nice idea but it needs to be checked for security/bugs... the last SMB_v1 caused havok around the world

            Comment


            • #7
              CIFS, SMB, Samba, and NFS are technolgies used to network client and server systems. Learn the difference between them and which to use when.


              1.) The CIFS implementation of SMB is rarely used these days. Under the covers, most modern storage systems no longer use CIFS, they use SMB 2 or SMB 3. In the Windows world, SMB 2 has been the standard as of Windows Vista (2006) and SMB 3 is part of Windows 8 and Windows Server 2012.

              2.) CIFS has a negative connotation amongst pedants. SMB 2 and SMB 3 are massive upgrades over the CIFS dialect, and storage architects who are near and dear to file sharing protocols don’t appreciate the misnomer. It’s kind of like calling an executive assistant a secretary.

              Comment


              • #8
                Originally posted by flower View Post
                what about nfs?
                That's always been the biggest pain points of NFS usage for me. In-kernel is so much more unflexible :-(
                - no clearly defined daemon process to start/stop/kill/troubleshoot
                - you are stuck with the nfs implementation coming with the kernel, can not bump its version without an os upgrade
                - containers all share the nfs implementation of the underlying kernel - not easy to containerize
                - since it's always been available 'for free' in the kernel, there's no userspace alternative widely used and maintained

                True, my usecases are not focused massive file serving. I dearly hope that this will not slowly take the place of samba, though.

                And I'm not even _thinking_ about the security implications...

                Comment


                • #9
                  Originally posted by gggeek View Post

                  That's always been the biggest pain points of NFS usage for me. In-kernel is so much more unflexible :-(
                  - no clearly defined daemon process to start/stop/kill/troubleshoot
                  - you are stuck with the nfs implementation coming with the kernel, can not bump its version without an os upgrade
                  - containers all share the nfs implementation of the underlying kernel - not easy to containerize
                  - since it's always been available 'for free' in the kernel, there's no userspace alternative widely used and maintained

                  True, my usecases are not focused massive file serving. I dearly hope that this will not slowly take the place of samba, though.

                  And I'm not even _thinking_ about the security implications...
                  I agree with you that a user-space option is more flexible. We do have Ganesha NFS server which is used by Ceph and others.

                  As for logging and debugging, there are debug flags that can be used with the kernel nfs. I wrote briefly about it here: https://wiki.tnonline.net/w/Blog/NFS_Server_Logging

                  In most parts of the world, people use NFS 3. This is 30 years old and is rather poorly suited for modern use IMHO. https://tools.ietf.org/html/rfc1813

                  ​​​
                  Last edited by S.Pam; 18 March 2021, 10:43 AM.

                  Comment


                  • #10
                    Originally posted by Naib View Post

                    When you need to access a windows machine.

                    Nice idea but it needs to be checked for security/bugs... the last SMB_v1 caused havok around the world
                    SMB1 was rather old.. Used 20 years ago and people should not have used such old systems without patching or upgrading. Do we have any current major issues with SMB3? Even SMB2 is 17 years old...

                    Comment

                    Working...
                    X