{"id":1078,"date":"2010-11-22T15:03:41","date_gmt":"2010-11-22T15:03:41","guid":{"rendered":"http:\/\/mccltd.net\/blog\/?p=1078"},"modified":"2010-11-22T15:11:24","modified_gmt":"2010-11-22T15:11:24","slug":"smb-opportunistic-locking","status":"publish","type":"post","link":"http:\/\/darenmatthews.com\/blog\/?p=1078","title":{"rendered":"SMB Opportunistic Locking"},"content":{"rendered":"

Concurrent writes to a single file are not desirable in any operating system. To prevent this, most operating systems use locks<\/em> to guarantee that only one process can write to a file at a time. Operating systems traditionally lock entire files, although newer ones allow a range of bytes within a file to be locked. If another process attempts to write to a file (or section of one) that is already locked, it will receive an error from the operating system and will wait until the lock is released.<\/p>\n

Samba supports the standard DOS and NT filesystem (deny-mode) locking requests, which allow only one process to write to an entire file on a server at a give time, as well as byte-range locking. In addition, Samba supports a new locking mechanism known in the Windows NT world as opportunistic locking – <\/em> oplock<\/em> for short.<\/p>\n

\n

Opportunistic Locking<\/a><\/h3>\n

Opportunistic locking allows a client to notify the Samba server that it will not only be the exclusive writer of a file, but will also cache its changes to that file on its own machine (and not on the Samba server) in order to speed up file access for that client. When Samba knows that a file has been opportunistically locked by a client, it marks its version as having an opportunistic lock and waits for the client to complete work on the file, at which point it expects the client to send the final changes back to the Samba server for synchronization.<\/p>\n

If a second client requests access to that file before the first client has finished working on it, Samba can send an oplock break<\/em> request to the first client. This tells the client to stop caching its changes and return the current state of the file to the server so that the interrupting client can use it as it sees fit. An opportunistic lock, however, is not a replacement for a standard deny-mode lock. It is not unheard of for the interrupting process to be granted an oplock break only to discover that the original process also has a deny-mode lock on a file as well. The table below illustrates this opportunistic locking process.<\/p>\n

Opportunistic locking<\/a><\/h4>\n

\"Opportunistic<\/a>In terms of locks, we highly recommend using the defaults provided by Samba: standard DOS\/Windows deny-mode locks for compatibility and oplocks for the extra performance that local caching allows. If your operating system can take advantage of oplocks, it should provide significant performance improvements. Unless you have a specific reason for changing any of these options, it’s best to leave them as they are.<\/div>\n

\n

Unix and Locking<\/a><\/h3>\n

Windows systems cooperate well to avoid overwriting each other’s changes. But if a file stored on a Samba system is accessed by a Unix process, this process won’t know a thing about Windows oplocks and could easily ride roughshod over a lock. Some Unix systems have been enhanced to understand the Windows oplocks maintained by Samba. Currently the support exists only in SGI Irix 6.5.2f and later; Linux and FreeBSD should soon follow.<\/p>\n

If you have a system that understands oplocks, set kernel<\/code> oplocks<\/code> =<\/code> yes<\/code> in the Samba configuration file. That should eliminate conflicts between Unix processes and Windows users.<\/p>\n

If your system does not support kernel oplocks, you could end up with corrupted data when somebody runs a Unix process that reads or writes a file that Windows users also access. However, Samba provides a rough protection mechanism in the absence of kernel oplocks: the veto<\/code> oplock<\/code> files<\/code> option. If you can anticipate which Samba files are used by both Windows users and Unix users, set their names in a veto<\/code> oplock<\/code> files<\/code> option. This will suppress the use of oplocks on matching filenames, which will supress client caching, and let the Windows and Unix programs use system locking or update times to detect competition for the same file. A sample option is:<\/p>\n

veto oplock files = \/*.dbm\/<\/pre>\n
This option allows both Unix processes and Windows users to edit files ending in the suffix  .dbm<\/em>. Note that the syntax of this option is similar to  veto<\/code>  files<\/code>.<\/p>\n
Samba’s options for locks and oplocks are given in the table below:
\n<\/a><\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
  Locks and Oplocks Configuration Options <\/a><\/caption>\n
Option<\/th>\nParameters<\/th>\nFunction<\/th>\nDefault<\/th>\nScope<\/th>\n<\/tr>\n<\/thead>\n
 share modes<\/code><\/td>\nboolean<\/td>\nIf set to  yes<\/code>, turns on support for DOS-style whole-file locks.<\/td>\n yes<\/code><\/td>\nShare<\/td>\n<\/tr>\n
 locking<\/code><\/td>\nboolean<\/td>\nIf  yes<\/code>, turns on byte-range locks.<\/td>\n yes<\/code><\/td>\nShare<\/td>\n<\/tr>\n
 strict locking<\/code><\/td>\nboolean<\/td>\nIf  yes<\/code>, denies access to an entire file if a byte-range lock exists in it.<\/td>\n no<\/code><\/td>\nShare<\/td>\n<\/tr>\n
 oplocks<\/code><\/td>\nboolean<\/td>\nIf  yes<\/code>, turn on local caching of files on the client for this share.<\/td>\n yes<\/code><\/td>\nShare<\/td>\n<\/tr>\n
 kernel oplocks<\/code><\/td>\nboolean<\/td>\nIf  yes<\/code>, indicates that the kernel supports oplocks.<\/td>\n yes<\/code><\/td>\nGlobal<\/td>\n<\/tr>\n
 fake oplocks<\/code><\/td>\nboolean<\/td>\nIf  yes<\/code>, tells client the lock was obtained, but doesn’t actually lock it.<\/td>\n no<\/code><\/td>\nShare<\/td>\n<\/tr>\n
 blocking locks <\/code><\/td>\nboolean<\/td>\nAllows lock requestor to wait for the lock to be granted.<\/td>\n yes<\/code><\/td>\nShare<\/td>\n<\/tr>\n
 veto oplock files<\/code><\/td>\nstring (list of filenames)<\/td>\nDoes not oplock specified files.<\/td>\nNone<\/td>\nShare<\/td>\n<\/tr>\n
 lock directory<\/code><\/td>\nstring (fully-qualified pathname)<\/td>\nSets the location where various Samba files, including locks, are stored.<\/td>\nAs specified in Samba makefile<\/td>\nGlobal<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n
 share modes<\/a><\/h4>\n
The most primitive locks available to Samba are deny-mode locks, known as  share modes<\/em>, which are employed by programs such as text editors to  avoid accidental overwriting of files. For reference, the deny-mode  locks are listed in the table below:<\/p>\n\n\n\n\n\n\n\n\n\n\n
  SMB Deny-Mode Locks <\/a><\/caption>\n
Lock<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
 DENY_NONE<\/code><\/td>\nDo not deny any other file requests.<\/td>\n<\/tr>\n
 DENY_ALL<\/code><\/td>\nDeny all open requests on the current file.<\/td>\n<\/tr>\n
 DENY_READ<\/code><\/td>\nDeny any read-only open requests on the current file.<\/td>\n<\/tr>\n
 DENY_WRITE<\/code><\/td>\nDeny any write-only open requests on the current file.<\/td>\n<\/tr>\n
 DENY_DOS<\/code><\/td>\nIf opened for reading, others can read but cannot write to the file. If opened for writing, others cannot open the file at all.<\/td>\n<\/tr>\n
 DENY_FCB<\/code><\/td>\nObsolete.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The  share<\/code>  modes<\/code> parameter, which enforces the use of these locks, is enabled by default. To disable it, use the following command:<\/p>\n
[accounting]\r\n\tshare modes = no<\/pre>\n
We highly recommend against disabling the default locking mechanism  unless you have a justifiable reason for doing so. Most Windows and DOS  applications rely on these locking mechanisms in order to work  correctly, and will complain bitterly if this functionality is taken  away.<\/p><\/div>\n
\n
 locking<\/a><\/h4>\n
The  locking<\/code> option can be used to tell Samba to engage or disengage  server-side byte-range locks on behalf of the client. Samba implements  byte-range locks on the server side with normal Unix advisory locks and  will consequently prevent other properly-behaved Unix processes from  overwriting a locked byte range.<\/p>\n
This option can be specified per share as follows:<\/p>\n
[accounting]\r\n\tlocking = yes<\/pre>\n
If the  locking<\/code> option is set to  yes<\/code>, the requestor will be delayed until the holder of either  type of lock releases it (or crashes). If, however, the option is set to   no<\/code>, no byte-range locks will be kept for the files, although  requests to lock and unlock files will appear to succeed. The option is  set to  yes<\/code> by default; however, you can turn this option off if you have read-only media.<\/div>\n
\n
 strict locking<\/a><\/h4>\n
This option checks every file access for a byte-range lock on the range  of bytes being accessed. This is typically not needed if a client  adheres to all the locking mechanisms in place. This option is set to  no<\/code> by default; however, you can reset it per share as follows:<\/p>\n
[accounting]\r\n\tstrict locking = yes<\/pre>\n
If this option is set to  yes<\/code>, mandatory locks are enforced on any file with byte-range locks.<\/div>\n
\n
 blocking locks<\/a><\/h4>\n
Samba also supports  blocking locks<\/em>, a minor variant of range locks. Here, if the range  of bytes is not available, the client specifies an amount of time that  it’s willing to wait. The server then caches the lock request,  periodically checking to see if the file is available. If it is, it  notifies the client; however, if time expires, Samba will tell the  client that the request has failed. This strategy prevents the client  from continually polling to see if the lock is available.<\/p>\n
You can disable this option per share as follows:<\/p>\n
[accounting]\r\n\tblocking locks = no<\/pre>\n
When set to  yes<\/code>, blocking locks will be enforced on the file. If this option is set to  no<\/code>, Samba behaves as if normal locking mechanisms are in place on the file. The default is  yes<\/code>.<\/div>\n
\n
 oplocks<\/a><\/h4>\n
This option enables or disables support for oplocks on the client. The  option is enabled by default. However, you can disable it with the  following command:<\/p>\n
[data]\r\n\toplocks = no<\/pre>\n
If you are in an extremely unstable network environment or have many  clients that cannot take advantage of opportunistic locking, it may be  better to shut this Samba feature off. Oplocks should be disabled if you  are accessing the same files from both Unix applications (such as  vi <\/em> ) and SMB clients (unless you are lucky enough to have an operating system that supports kernel oplocks as discussed earlier).<\/div>\n
\n
 fake oplocks<\/a><\/h4>\n
Before opportunistic locking was available on Samba, the Samba daemons pretended to allow oplocks via the  fake<\/code>  oplocks<\/code> option. If this option was enabled, all clients were told  that the file is available for opportunistic locking, and never warned  of simultaneous access. This option is deprecated now that real oplocks  are available on Samba.<\/div>\n
\n
 kernel oplocks<\/a><\/h4>\n
If a Unix application separate from Samba tries to update a file that  Samba has oplocked to a Windows client, it will likely succeed  (depending on the operating system) and both Samba and the client will  never be aware of it. However, if the local Unix operating system  supports it, Samba can warn it of oplocked files, which can suspend the  Unix process, notify the client via Samba to write its copy back, and  only then allow the open to complete. Essentially, this means that the  operating system kernel on the Samba system has the ability to handle  oplocks as well as Samba.<\/p>\n
You can enable this behavior with the  kernel<\/code>  oplocks<\/code> option, as follows:<\/p>\n
[global]\r\n\tkernel oplocks = yes<\/pre>\n
Samba can automatically detect kernel oplocks and use them if present.  At the time of this writing, this feature is supported only by SGI Irix  6.5.2f and later. However, Linux and FreeBSD support are expected in the  near future. A system without kernel oplocks will allow the Unix  process to update the file, but the client programs will notice the  change only at a later time, if at all.<\/p><\/div>\n
\n
 veto oplock files<\/a><\/h4>\n
You can provide a list of filenames that are never granted opportunistic locks with the  veto<\/code>  oplock<\/code>  files<\/code> option. This option can be set either globally or on a per-share basis. For example:<\/p>\n
veto oplock files = \/*.bat\/*.htm\/<\/pre>\n
The value of this option is a series of patterns. Each pattern entry  must begin, end, or be separated from another with a slash ( \/ )  character, even if there is only one pattern listed. Asterisks can be  used as a wildcard to represent zero or more characters. Questions marks  can be used to represent exactly one character.<\/p>\n
We recommend that you disable oplocks on any files that are meant to be  updated by Unix or are intended to be shared by several processes  simultaneously.<\/p><\/div>\n
\n
 lock directory<\/a><\/h4>\n
This option (sometimes called  lock<\/code>  dir<\/code>) specifies the location of a directory where Samba will store  SMB deny-mode lock files. Samba stores other files in this directory as  well, such as browse lists and its shared memory file. If WINS is  enabled, the WINS database is written to this directory as well. The  default for this option is specified in the Samba makefile; it is  typically  \/usr\/local\/samba\/var\/locks<\/em>. You can override this location as follows:<\/p>\n
[global]\r\n\tlock directory = \/usr\/local\/samba\/locks<\/pre>\n
You typically would not need to override this option, unless you want to  move the lock files to a more standardized location, such as  \/var\/spool\/locks<\/em>.<\/p>\n
Source:<\/p><\/div>\n<\/div>\n
Source:
\n\"\"<\/a>\"\"<\/p>\n","protected":false},"excerpt":{"rendered":"
Concurrent writes to a single file are not desirable in any operating system. To prevent this, most operating systems use locks to guarantee that only one process can write to a file at a time. Operating systems traditionally lock entire files, although newer ones allow a range of bytes within a file to be locked. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[27],"tags":[49],"_links":{"self":[{"href":"http:\/\/darenmatthews.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1078"}],"collection":[{"href":"http:\/\/darenmatthews.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/darenmatthews.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/darenmatthews.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/darenmatthews.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1078"}],"version-history":[{"count":10,"href":"http:\/\/darenmatthews.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1078\/revisions"}],"predecessor-version":[{"id":1089,"href":"http:\/\/darenmatthews.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1078\/revisions\/1089"}],"wp:attachment":[{"href":"http:\/\/darenmatthews.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1078"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/darenmatthews.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1078"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/darenmatthews.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1078"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}