下面的3行网上说可以用来解决samba和nfs互访速度奇慢问题,但是并不奏效,后来发现mount-t nfs -o nolock可以解决这个问题,如果nfs和samba之间不能拖动复制,可以使用ctrl+c 和ctrl+v组合
samba和nfs互相拷贝时速度奇慢的原因,但是个人不推荐locking = no,因为这样存在很大问题,如果需要windows下nfs,那么可以安装windows的nfs工具[gloabl]strict locking = noposix locking = nokernel oplocks = no
Samba
2.* default was "strict locking = no", and
3.* is "strict locking= yes".
If you have "strict locking" set over an NFS mount, it will be very slow.
"strict locking" or even "locking" should not be touched.
"posix locking = no" is advisable for sharing NFS imports.
Beyond "posix locking = no" please also set
"kernel oplocks = no". Then depending on the quality of your NFS client
implementation you could get to a working server.
Locks and Oplocks
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,oroplock for short.
8.5.1 Opportunistic Locking
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.
Figure
8-11. Opportunistic locking
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.
8.5.2 Unix and Oplocks
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.
8.5.3 Locks and Oplocks Configuration
Options
Samba's options for
locks and oplocks are given in .
Table 8-6. Locks and oplocks
configuration optionsOption
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
8.5.3.1 locking
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.
8.5.3.2
strict locking
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.
8.5.3.3
posix locking
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.
8.5.3.4
oplocks
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.
8.5.3.5
kernel oplocks
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.
8.5.3.6
level2 oplocks
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.
8.5.3.7
fake oplocks
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.
8.5.3.8 blocking locks
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.
8.5.3.9
veto oplock files
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.
8.5.3.10
lock directory
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.