ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Windows and NFS

    Water Closet
    4
    23
    1.3k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • scottalanmillerS
      scottalanmiller @brandon220
      last edited by

      @brandon220 said in Windows and NFS:

      @scottalanmiller This is true. I forgot about my ReadyNAS units allowing multiple protocols.

      I thought that they did too. Most everyone does, and nearly everyone uses Samba under the hood.

      1 Reply Last reply Reply Quote 0
      • 1
        1337 @scottalanmiller
        last edited by 1337

        @scottalanmiller said in Windows and NFS:

        @Pete-S said in Windows and NFS:

        @scottalanmiller said in Windows and NFS:

        @brandon220 said in Windows and NFS:

        @Pete-S The locking is also what I was referring to. I will most likely set the share up for both and do some testing.

        There should be locking from the filesystem so that either Samba or NFS has the file at any given moment. It's the filesystem's job to make sure that two processes can't access any given file at the same time. That the processes are NFS or Samba shouldn't matter. NFS or SMB can have another partial lock on top of that, for sure. But that should be on top of the file level lock.

        That is an incorrect assumption. Read this: https://en.wikipedia.org/wiki/File_locking

        Which part? I read the part of NFS, but that doesn't seem to apply. That would cause problems, but not corruption problems, right?

        Just that comparing windows and *nix you see that there are different file locking mechanisms in play. That is what could cause corruption. Samba has to support Windows mechanisms while it's file system is residing on unix.

        For instance from Samba 3.0 documentation (for historical context only):

        Record locking semantics under UNIX are very different from record locking under Windows. Versions of Samba before 2.2 have tried to use the native fcntl() UNIX system call to implement proper record locking between different Samba clients. This cannot be fully correct for several reasons. The simplest is that a Windows client is allowed to lock a byte range up to 2^32 or 2^64, depending on the client OS. The UNIX locking only supports byte ranges up to 2^31. So it is not possible to correctly satisfy a lock request above 2^31. There are many more differences, too many to be listed here.

        Samba 2.2 and above implement record locking completely independently of the underlying UNIX system. If a byte-range lock that the client requests happens to fall into the range of 0 to 2^31, Samba hands this request down to the UNIX system. No other locks can be seen by UNIX, anyway.

        scottalanmillerS 1 Reply Last reply Reply Quote 0
        • scottalanmillerS
          scottalanmiller @1337
          last edited by

          @Pete-S said in Windows and NFS:

          @scottalanmiller said in Windows and NFS:

          @Pete-S said in Windows and NFS:

          @scottalanmiller said in Windows and NFS:

          @brandon220 said in Windows and NFS:

          @Pete-S The locking is also what I was referring to. I will most likely set the share up for both and do some testing.

          There should be locking from the filesystem so that either Samba or NFS has the file at any given moment. It's the filesystem's job to make sure that two processes can't access any given file at the same time. That the processes are NFS or Samba shouldn't matter. NFS or SMB can have another partial lock on top of that, for sure. But that should be on top of the file level lock.

          That is an incorrect assumption. Read this: https://en.wikipedia.org/wiki/File_locking

          Which part? I read the part of NFS, but that doesn't seem to apply. That would cause problems, but not corruption problems, right?

          Just that comparing windows and *nix you see that there are different file locking mechanisms in play. That is what could cause corruption. Samba has to support Windows mechanisms while it's file system is residing on unix.

          For instance from Samba 3.0 documentation (for historical context only):

          Record locking semantics under UNIX are very different from record locking under Windows. Versions of Samba before 2.2 have tried to use the native fcntl() UNIX system call to implement proper record locking between different Samba clients. This cannot be fully correct for several reasons. The simplest is that a Windows client is allowed to lock a byte range up to 2^32 or 2^64, depending on the client OS. The UNIX locking only supports byte ranges up to 2^31. So it is not possible to correctly satisfy a lock request above 2^31. There are many more differences, too many to be listed here.

          Samba 2.2 and above implement record locking completely independently of the underlying UNIX system. If a byte-range lock that the client requests happens to fall into the range of 0 to 2^31, Samba hands this request down to the UNIX system. No other locks can be seen by UNIX, anyway.

          That's very complex. But it sounds like Samba is just... not locking the file and hoping for the best?

          1 Reply Last reply Reply Quote 0
          • 1
          • 2
          • 2 / 2
          • First post
            Last post