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.

Tags: NAS, oplock,

Related Articles: