下面的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.