On 10/14/08 14:19, Daniel Liebster wrote:
> Thanks Alan!
> I enabled opslock as described, and had to disable/enable the smb/server
> service to make the change take. After this I went from > 1200 second
> benchmarks down to 8 - 10 seconds, inline with Windows 2003 and hardware
> based file server(BlueArc).
>
> Alan, could you please post the Pros and Cons to oplocks in CIFS?
>
> Thanks,
>
> Dan
The premise is that opportunistic locks (oplocks) allow clients to
cache data and users should perceive a performance benefit. NFSv4
has a simialr concept known as delegation. In SMB/CIFS recalling
cached data is known as an oplock break, in NFSv4 it's known as a
recall. For those who want specifics, there are lots of references
on the Internet.
For normal file sharing, oplocks can be left enabled. The mechanism
is transparent to users and, unless there is contention on individual
files, the caching should improve performance - sometimes dramatically,
as seen in this discussion. CIFS and/or NFSv4 will be notified by
the operating system when a conflicting open occurs and they will
break/recall as appropriate. If there are a number of users
simultaneously updating a single file (perhaps a spreadsheet), it may
be worth disabling oplocks but, otherwise, it should be okay to leave
oplocks enabled and let clients and servers work things out.
The main reason for disabling oplocks is when write ordering is important,
which is required by databases using write-ahead logging (journaling).
If the client is caching writes then the database cannot ensure that
its journal records are committed to the server's disk before file
content. If there is a problem (crash, network outage) while the client
is flushing cached data back to the server, the database may not be able
to recover. So most database vendors recommend (insist) that oplocks be
disabled on file systems being used by the database.
The main quoted concern w.r.t. UNIX is that UNIX and NFS use advisory
locking. Advisory locking is not enforced by the operating system and
requires that applications/processes cooperate to ensure consistency.
SMB/CIFS relies on mandatory locking and it is assumed that the operating
system will enforce locks regardless of the application or process.
Solaris supports system-wide mandatory locking via a mount option
(mount -o nbmand), thus the concern cited above can be resolved on a
per file system basis. When nbmand is enabled, the operating system
enforces mandatory locks across all process and applications. Note that
even when nbmand is not enabled, the CIFS service enforces mandatory
locking for SMB/CIFS connections.
Non-blocking mandatory locking (nbmand) has been in Solaris for a while
but we are making a change. The current nbmand implementation correlates
range locks and share reservations when checking whether or not to allow
an operation to proceed. This is incorrect and can result in unexpected
request failures (sharing violations in Windows/SMB terms). The changes
are described in PSARC 2008/584 and CR 6734067, and the change is already
tested and ready for putback. I would recommend waiting for this update
before using nbmand.
Another, very rare, issue is the delete deadlock, which is described in
various Microsoft knowledge base articles:
http://support.microsoft.com/kb/885451
http://support.microsoft.com/kb/811492
When an oplock is being broken, the server gives a client up to 30 seconds
to flush data to the server. After 30 seconds, the server gives up and
allows a second client to proceed. The implication here is that the second
client may have to wait for 30 seconds for a file open request to complete
if the first client is not responding. Normally the exchange happens
quickly and it's not an issue.
The delete deadlock occurs if a client has a file open with an oplock and
then tries to delete the file. The server issues the oplock break but the
client can't process it because it's waiting on the delete response. The
result is a 30 second delay while the oplock break times out, and things
continue. If you encounter this problem, you might consider disabling
oplocks.
As I mentioned previously, we have not enabled oplocks by default yet
because we haven't fully tested the implementation but we are going to
try to get through that testing as a high priority.
Alan
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
