SMB and Opportunistic Locking

Improving file access performance with behind-the-scenes caching

One of the ways in which Server 2008’s new version of the Server Message Block protocol improves performance over the original version of SMB is through something called “opportunistic locking,” or “oplocks” for short. The idea is that a client accessing a shared file can cache the file’s data for reuse without having to travel the network link multiple times – classic caching technique. The only way the client can be sure that the cached file data hasn’t been changed is if the data gets locked out from writes by other clients. So the client places an “opportunistic lock” on the file, assuming the SMB server approves the request – for example, if nobody else has the file open for writing. If another user subsequently wants to write to the file, the SMB server has to break the lock and then the original client is going to lose the speed benefit of caching the data locally. With SMB version 1, you can disable oplocks if you want (it’s a Registry hack). There are situations in which they could create a net downgrade of performance and/or robustness, depending for example on the kind of database software you might be running. (Client/server databases might run faster and more happily with oplocks, but ISAM databases might run into data corruption issues.) However, you can’t turn oplocks off in SMB version 2. (Among other things, it would break the “offline files” feature if you did.) Remember, you’re only going to be using SMB 2.x if you’re running Longhorn machines on both ends. However, you can disable SMB 2.x entirely, which will allow the Registry setting disabling oplocks to work. With SMB version 2.1, running on Server 2008 R2 and Windows 7, Microsoft has tuned the oplocks feature so that it works better in situations where a single application might generate multiple opens to the same file, which apparently happens more often than one might suspect. Microsoft claims a performance benefit from this tweak, providing yet another argument for giving serious thought to R2 and Windows 7.

Copyright © 2010 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022