全部博文（2005）
分类： 系统运维
2010-03-21 09:49:11
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. If another process attempts to write to a file (or section of one) that is already locked, it receives an error from the operating system and will have to wait until the lock is released.
Samba supports the standard DOS and NT filesystem (deny-mode) locking requests梬hich allow only one process to write to an entire file on a server at a given time梐s well as byte-range locking. In addition, Samba supports a locking mechanism known in the Windows NT world as opportunistic locking, or oplock for short.
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 locally to speed up access by reducing network activity. This can result in a large performance gain梩ypically 30%梬hile at the same time reserving network bandwidth for other purposes.
Because exclusive access can be obtained using regular file locks, the value of opportunistic locks is not so much to lock the file as it is to cache it. In fact, a better name for opportunistic locking might be opportunistic caching.
When Samba knows that a file in one of its shares has been oplocked 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 its changes back to the Samba server for synchronization with the copy on the server.
If a second client requests access to that file before the first client has finished working on it, Samba sends an oplock break 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. illustrates this opportunistic locking process.
In most cases, the extra performance resulting from the use of oplocks is highly desirable. However, allowing the client to cache data can be a big risk if either the client or network hardware are unreliable. Suppose a client opens a file for writing, creating an oplock on it. When another client also tries to open the file, an oplock break request is sent to the first client. If this request goes unfulfilled for any reason and the second client starts writing to the file, the file can be easily corrupted as a result of the two processes writing to it concurrently. Unfortunately, this scenario is very real. Uncoordinated behavior such as this has been observed many times among Windows clients in SMB networks (with files served by Windows NT/2000 or Samba). Typically, the affected files are database files, which multiple clients open concurrently for writing.
A more concrete example of oplock failure occurs when database files are very large. If a client is allowed to oplock this kind of file, there can be a huge delay while the client copies the entire file from the server to cache it, even though it might need to update only one record. The situation goes from bad to worse when another client tries to open the oplocked file. The first client might need to write the entire file back to the server before the second client's file open request can succeed. This results in another huge delay (for both clients), which in practice often results in a failed open due to a timeout on the second client, perhaps along with a message warning of possible database corruption!
If you are having problems of this variety, you can turn off oplocks for the affected files by using the veto oplock files parameter:
[dbdata]
veto oplock files = /*.dbm/
Use the value of the parameter (a list of filename-matching patterns separated by slash characters) to match all the files in the share that might be a source of trouble. The syntax of this parameter is similar to that of the veto files parameter.
If you want to be really careful and can live with reduced performance, you can turn off oplocks altogether, preventing the oplock break problem from ever occurring:
[global]
oplocks = no
This disables oplocks for all files in all shares served by the Samba server. If you wish to disable oplocks in just a specific share, you can specify the oplocks = no parameter in just that share:
[database]
oplocks = no
This example allows other shares, which might have less sensitive data, to attain better performance, while trading performance for better data integrity for files in the [database] share.
Most of the time, oplocks help Windows client systems cooperate to avoid overwriting each other's changes. Unix systems also have file-locking mechanisms to allow Unix processes to cooperate with each other. But if a file stored on a Samba system is accessed by both a Windows network client and a local Unix process梬ithout an additional coordination between the two systems梩he Unix process could easily ride roughshod over an oplock.
Some Unix systems have enhanced kernels that understand the Windows oplocks maintained by Samba. Currently the support exists only in SGI Irix and Linux.
If you leave oplocks enabled and your Unix 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. This is another case where the veto oplock files parameter can be used, assuming you can anticipate which Samba files are used by both Windows users and Unix users. For example, suppose the [usrfiles] share contains some ASCII text files with the .txt filename extension and OpenOffice word processor documents with the .doc filename extension, which Unix and Windows users both modify. We can use veto oplock files like this:
[usrfiles]
veto oplock files = /*.txt/*.doc/
This will suppress the use of oplocks on .txt and .doc files, which will suppress client caching, while allowing the Windows and Unix programs to use regular file locking to prevent concurrent writes to the same file.
Samba's options for locks and oplocks are given in .
|
Option |
Parameters |
Function |
Default |
Scope |
|---|---|---|---|---|
|
locking |
Boolean |
If yes, turns on byte-range locks. |
yes |
Share |
|
strict locking |
Boolean |
If yes, denies access to an entire file if a byte-range lock exists in it. |
no |
Share |
|
posix locking |
Boolean |
If yes, maps oplocks to POSIX locks on the local system. |
yes |
Share |
|
oplocks |
Boolean |
If yes, turns on local caching of files on the client for this share. |
yes |
Share |
|
kernel oplocks |
Boolean |
If yes, indicates that the kernel supports oplocks. |
yes |
Global |
|
level2 oplocks |
Boolean |
If yes, allows oplocks to downgrade to read-only. |
yes |
Share |
|
fake oplocks |
Boolean |
If yes, tells client the lock was obtained, but doesn't actually lock it. |
no |
Share |
|
blocking locks |
Boolean |
Allows lock requestor to wait for the lock to be granted. |
yes |
Share |
|
veto oplock files |
string (list of filenames) |
Does not oplock specified files. |
None |
Share |
|
lock directory |
string (fully qualified pathname) |
Sets the location where various Samba files, including locks, are stored. |
As specified in Samba makefile |
Global |
The locking 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 consequently prevents other properly behaved Unix processes from overwriting a locked byte range.
This option can be specified per share as follows:
[accounting]
locking = yes
If the locking option is set to yes, the requestor is delayed until the holder of either type of lock releases it (or crashes). If, however, the option is set to no, no byte-range locks are kept for the files, although requests to lock and unlock files will appear to succeed. The option is set to yes by default; however, you can turn this option off if you have read-only media.
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 by default; however, you can reset it per share as follows:
[accounting]
strict locking = yes
If this option is set to yes, mandatory locks are enforced on any file with byte-range locks.
On systems that support POSIX locking, Samba automatically maps oplocks to POSIX locks. This behavior can be disabled by setting posix locking = no. You should never need to change the default behavior, which is posix locking = yes.
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:
[data]
oplocks = no
If you are in an extremely unstable network environment or have many clients that cannot take advantage of opportunistic locking, it might be better to shut this Samba feature off. If the host operating system does not support kernel oplocks, oplocks should be disabled if users are accessing the same files from both Unix applications (such as vi) and SMB clients.
If a Unix application on the Samba host system (that is not part of the Samba suite) tries to open a file for writing that Samba has oplocked to a Windows client, it is likely to succeed (depending on the operating system), and both Samba and the client are never aware of it.
Some versions of Unix have support for oplocks in the kernel that can work along with Samba's oplocks. In this case, the Unix process trying to open the file is suspended while Samba directs the client to write its copy back. After that has happened, the operating system allows the open to complete. At the time of this writing, this feature is supported only by SGI Irix and Linux.
Windows NT/2000/XP clients can downgrade their read-write oplocks to read-only oplocks when another client opens the same file. This can result in significant improvements in performance on files that are written infrequently or not at all梕specially executables梑ecause all clients can then maintain a read-ahead cache for the file. By default, level2 oplocks is set to yes, and you probably won't need to change it.
Currently, Samba cannot support level 2 oplocks along with kernel oplocks and automatically disables level 2 oplocks when kernel oplocks are in use. (This might change in future releases as improved support for oplocks is added by the Samba developers.) If you are running Samba on a host system that supports kernel oplocks, you must set kernel oplocks = no to enable support for level 2 oplocks.
Disabling oplocks with oplocks = no also disables level 2 oplocks.
Samba can automatically detect its Unix host's support of kernel oplocks and will set the value of kernel oplocks automatically. You should never need to set this option in your Samba configuration file.
When this option is set to yes, Samba pretends to allow oplocks rather than actually supporting them. If this option is enabled on a read-only share (such as a shared CD-ROM drive), all clients are told that the files are available for opportunistic locking and never warned of simultaneous access. As a result, Windows clients cache more of the file's data and obtain much better performance.
This option was added to Samba before opportunistic-locking support was available, and it is now generally considered better to use real oplocks. Do not ever enable fake oplocks on a read/write share.
Samba also supports blocking locks, 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.
You can disable this option per share as follows:
[accounting]
blocking locks = no
When set to yes, blocking locks are enforced on the file. If this option is set to no, Samba behaves as if normal locking mechanisms are in place on the file. The default is yes.
You can provide a list of filenames that are never granted opportunistic locks with the veto oplock files option. This option can be set either globally or on a per-share basis. For example:
veto oplock files = /*.bat/*.htm/
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 only one pattern is listed. Asterisks can be used as a wildcard to represent zero or more characters. Questions marks can be used to represent exactly one character.
We recommend that you disable oplocks on any files that are meant to be updated by Unix or are intended for simultaneous sharing by several processes.
This option (sometimes called lock dir) 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. You can override this location as follows:
[global]
lock directory = /usr/local/samba/locks
You typically would not need to override this option, unless you want to move the lock files to a more standard location, such as /var/spool/locks.
