HP CIFS Opportunistic Locking Usage Guidelines

11
where the network is slow or unreliable, an oplock break can become lost without the user
even accessing a file. This can cause apparent performance degradation as the client
continually reconnects to overcome the lost oplock break.
So avoid the following combination:
• “force user” in smb.conf share configuration, and
• Slow or unreliable networks, and
• Opportunistic locking
4.8 Advanced Samba Opportunistic Locking Parameters
Samba provides opportunistic locking parameters that allow the administrator to adjust
various properties of the oplock mechanism to account for timing and usage levels. These
parameters provide good versatility for implementing oplocks in environments where they
would likely cause problems. The parameters are:
• oplock break wait time
• oplock contention limit
For most users, administrators, and environments, if these parameters are required, then
the better option is to simply turn oplocks off. The samba SWAT help text for both
parameters reads “DO NOT CHANGE THIS PARAMETER UNLESS YOU HAVE READ
AND UNDERSTOOD THE SAMBA OPLOCK CODE.” This is good advice.
4.9 Mission Critical High Availability
In mission critical high availability environments, data integrity is often a priority. Complex
and expensive configurations are implemented to ensure that if a client loses connectivity
with a file server, a failover replacement will be available immediately to provide continuous
data availability.
Windows client failover behavior is more at risk of application interruption than other
platforms because it is dependant upon an established TCP transport connection. If the
connection is interrupted – as in a file server failover – a new session must be established. It
is rare for Windows client applications to be coded to recover correctly from a transport
connection loss, therefore most applications will experience some sort of interruption – at
worst, abort and require restarting.
If a client session has been caching writes and reads locally due to opportunistic locking, it is
likely that the data will be lost when the application restarts, or recovers from the TCP
interrupt. When the TCP connection drops, the client state is lost. When the file server
recovers, an oplock break is not sent to the client. In this case, the work from the prior
session is lost. Observing this scenario with oplocks disabled, and the client was writing
data to the file server real-time, then the failover will provide the data on disk as it existed at
the time of the disconnect.
In mission critical high availability environments, careful attention should be given to
opportunistic locking. Ideally, comprehensive testing should be done with all affected
applications with oplocks enabled and disabled.