Background
I recently learned something about NASes that buyers looking to use these products for database and other simultaneous-file-access applications should know about. The issue is how Opportunistic Locking ("oplocks") are handled.
For those who are unfamiliar with oplocks, this excerpt from a SuperBase article explains:
Opportunistic locks (oplocks) are a characteristic of theLAN Manager networking protocol implemented in the 32-Bit Windows family of operating system environments. Bascially, oplocks are guarantees made by a server for a shared logical volume to its clients. These guarantees inform the Client that a file’s content will not be allowed to be changed by the server, or if some change is imminent, the client will be notified before the change is allowed to proceed.
Note that oplocks are part of the SMB/CIFS protocol, so don’t apply to systems using AFP, NFS or other networked filesystem protocols. But as part of SMB/CIFS, oplocks are implemented in Samba, the open source re-implementation of SMB/CIFS used by all Linux-based NASes.
I also checked with filesystem expert Don Capps, creator of iozone, which I use for all NAS testing. Don had the following comments on oplocks (which I’ve lightly edited):
Oplocks are on by default in all Windows clients and
servers. The purpose is to enable the client to perform a locking operation and write data to a file. As long as no one else is touching the file,
the lock operation happens on the remote client and
no one is the wiser. This is a huge performance win.However, if multiple clients are trying to read or write to the same file, then oplocks is a huge performance loser. The problem is that the first client
gets the oplock granted by the server and begins work.
Then up comes the second client. The server sees the possible conflict and sends a Revoke lock operation to the first client and lets both of them know that
oplock requests will not work on this file due to multiple concurrent clients trying to access it. As this point all locking operations are sent to, and handled by, the server.SO… We can generalize here. If there exists any
file that is going to be shared by multiple clients
then it would be a really good idea to disable oplocks on the clients, or the server. This would eliminate the lock revocation from the system, and
would eliminate extra overhead that is associated
with oplocks. Note that the entire discussion of when to use, and when not to use oplocks is discussed in most Samba books.
Don goes on to offer the following suggestions (bolding is mine):
1. If a system (clients and server) will be used to perform shared file operations,
then oplocks should be disabled.2. If a system will be used to perform non-shared operations,
then oplocks is a huge performance win, and should be enabled.3. If a system will be used for both
shared and non-shared file accesses, then the exported shares with the shared files should
have oplocks disabled, and all other shares should have oplocks enabled.4. If anyone tells you to set all oplocks on, or off
for a general purpose (shared, and non-shared files)
system, then this person is either being silly, or
does not understand oplocks, and their proper usage.
Options
Unfortunately, most NASes take the all-on or all-off approach to oplocks, for various reasons. One vendor that I checked with pointed to problems with certain versions of Samba and also certain applications, so has defaulted its product to opplocks-off, but offers an add-on for users who want them enabled. This same vendor plans to change the default to enabling oplocks in an upcoming firmware update, but will provide an option in its management GUI to disable them.
Another NAS vendor defaults its products to oplocks-on for all shares, but offers a "database optimization" mode to disable oplocks on all shares. Yet another vendor started with having its NAS default to enabling oplocks, but changed the default to disable after experiencing problems oplocks getting stuck on when clients disconnected before closing an opened file. This vendor is currently evaluating alternative approaches.
Since it is Windows clients (or to be specific, clients running the SMB protocol) that set the oplocks, one would hope that this feature could be disabled there. This Microsoft KB article describes the Registry edits to do just that, except for Vista. (If you need the regedits for Win NT, use this KB article.) To further complicate the issue, Microsoft introduced a new version of the SMB protocol—SMB2—in Vista, which does not allow oplocks to be disabled.
So, what’s the bottom line? Don Capps’ advice above seems to provide a good set set of recommendations. Unfortunately, most consumer NASes don’t provide share-by-share control of oplocks. So the next best thing seems to be the path that many NAS vendors are taking; disabling oplocks. This seems to minimize application-specific NAS problems and has the benefit of improved throughput.
Since vendors don’t provide information on their oplock approach, however, you may have to experiment for yourself by using the Windows Registry hacks referenced above and doing your own testing. I’m interested in what you find, so post a comment and share your results.