On 10/15/08 2:13 AM, "Alan M Wright" <[EMAIL PROTECTED]> wrote:
> 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 I brought up this issue a few months ago, and Janice recommended against enabling oplocks on solaris cifs: http://mail.opensolaris.org/pipermail/cifs-discuss/2008-July/000394.html I still think that oplocks and solaris cifs needs to be documented better. _______________________________________________ cifs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
