SAMBA Project Documentation
Prev		Next

Chapter 3. Oplocks

3.1. What are oplocks?

When a client opens a file it can request an "oplock" or file +lease. This is (to simplify a bit) a guarentee that no one else +has the file open simultaneously. It allows the client to not +send any updates on the file to the server, thus reducing a +network file access to local access (once the file is in +client cache). An "oplock break" is when the server sends +a request to the client to flush all its changes back to +the server, so the file is in a consistent state for other +opens to succeed. If a client fails to respond to this +asynchronous request then the file can be corrupted. Hence +the "turn off oplocks" answer if people are having multi-user +file access problems.

Unless the kernel is "oplock aware" (SGI IRIX and Linux are +the only two UNIXes that are at the moment) then if a local +UNIX process accesses the file simultaneously then Samba +has no way of telling this is occuring, so the guarentee +to the client is broken. This can corrupt the file. Short +answer - it you have UNIX clients accessing the same file +as smbd locally or via NFS and you're not running Linux or +IRIX then turn off oplocks for that file or share.

"Share modes". These are modes of opening a file, that +guarentee an invarient - such as DENY_WRITE - which means +that if any other opens are requested with write access after +this current open has succeeded then they should be denied +with a "sharing violation" error message. Samba handles these +internally inside smbd. UNIX clients accessing the same file +ignore these invarients. Just proving that if you need simultaneous +file access from a Windows and UNIX client you *must* have an +application that is written to lock records correctly on both +sides. Few applications are written like this, and even fewer +are cross platform (UNIX and Windows) so in practice this isn't +much of a problem.

"Locking". This really means "byte range locking" - such as +lock 10 bytes at file offset 24 for write access. This is the +area in which well written UNIX and Windows apps will cooperate. +Windows locks (at least from NT or above) are 64-bit unsigned +offsets. UNIX locks are either 31 bit or 63 bit and are signed +(the top bit is used for the sign). Samba handles these by +first ensuring that all the Windows locks don't conflict (ie. +if other Windows clients have competing locks then just reject +immediately) - this allows us to support 64-bit Windows locks +on 32-bit filesystems. Secondly any locks that are valid are +then mapped onto UNIX fcntl byte range locks. These are the +locks that will be seen by UNIX processes. If there is a conflict +here the lock is rejected.

Note that if a client has an oplock then it "knows" that no +other client can have the file open so usually doesn't bother +to send to lock request to the server - this means once again +if you need to share files between UNIX and Windows processes +either use IRIX or Linux, or turn off oplocks for these +files/shares.

Prev	Home	Next
Improved browsing in samba	Up	Quick Cross Subnet Browsing / Cross Workgroup Browsing guide