Windows and NFS
-
@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.
-
@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.
-
@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?
