diff options
Diffstat (limited to 'docs/htmldocs/locking.html')
| -rw-r--r-- | docs/htmldocs/locking.html | 506 |
1 files changed, 252 insertions, 254 deletions
diff --git a/docs/htmldocs/locking.html b/docs/htmldocs/locking.html index 07228df19d..5210c015c0 100644 --- a/docs/htmldocs/locking.html +++ b/docs/htmldocs/locking.html @@ -1,97 +1,98 @@ -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 14. File and Record Locking</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="samba-doc.html" title="SAMBA Project Documentation"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="previous" href="AccessControls.html" title="Chapter 13. File, Directory and Share Access Controls"><link rel="next" href="securing-samba.html" title="Chapter 15. Securing Samba"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 14. File and Record Locking</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="AccessControls.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="securing-samba.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="locking"></a>Chapter 14. File and Record Locking</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Jeremy</span> <span class="surname">Allison</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jra@samba.org">jra@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jelmer</span> <span class="othername">R.</span> <span class="surname">Vernooij</span></h3><div class="affiliation"><span class="orgname">The Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Eric</span> <span class="surname">Roseme</span></h3><div class="affiliation"><span class="orgname">HP Oplocks Usage Recommendations Whitepaper<br></span><div class="address"><p><tt class="email"><<a href="mailto:eric.roseme@hp.com">eric.roseme@hp.com</a>></tt></p></div></div></div></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="locking.html#id2908532">Features and Benefits</a></dt><dt><a href="locking.html#id2908589">Discussion</a></dt><dd><dl><dt><a href="locking.html#id2908732">Opportunistic Locking Overview</a></dt></dl></dd><dt><a href="locking.html#id2909449">Samba Opportunistic Locking Control</a></dt><dd><dl><dt><a href="locking.html#id2909569">Example Configuration</a></dt></dl></dd><dt><a href="locking.html#id2909983">MS Windows Opportunistic Locking and Caching Controls</a></dt><dd><dl><dt><a href="locking.html#id2910208">Workstation Service Entries</a></dt><dt><a href="locking.html#id2910237">Server Service Entries</a></dt></dl></dd><dt><a href="locking.html#id2910317">Persistent Data Corruption</a></dt><dt><a href="locking.html#id2910345">Common Errors</a></dt><dd><dl><dt><a href="locking.html#id2910419">locking.tdb error messages</a></dt><dt><a href="locking.html#id2910456">Problems saving files in MS Office on Windows XP</a></dt><dt><a href="locking.html#id2910479">Long delays deleting files over network with XP SP1</a></dt></dl></dd><dt><a href="locking.html#id2910511">Additional Reading</a></dt></dl></div><p> -One area which causes trouble for many network administrators is locking. -The extent of the problem is readily evident from searches over the internet. -</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2908532"></a>Features and Benefits</h2></div></div><div></div></div><p> +<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 14. File and Record Locking</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="previous" href="AccessControls.html" title="Chapter 13. File, Directory and Share Access Controls"><link rel="next" href="securing-samba.html" title="Chapter 15. Securing Samba"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 14. File and Record Locking</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="AccessControls.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="securing-samba.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="locking"></a>Chapter 14. File and Record Locking</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Jeremy</span> <span class="surname">Allison</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jra@samba.org">jra@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jelmer</span> <span class="othername">R.</span> <span class="surname">Vernooij</span></h3><div class="affiliation"><span class="orgname">The Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Eric</span> <span class="surname">Roseme</span></h3><div class="affiliation"><span class="orgname">HP Oplocks Usage Recommendations Whitepaper<br></span><div class="address"><p><tt class="email"><<a href="mailto:eric.roseme@hp.com">eric.roseme@hp.com</a>></tt></p></div></div></div></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="locking.html#id2915945">Features and Benefits</a></dt><dt><a href="locking.html#id2916001">Discussion</a></dt><dd><dl><dt><a href="locking.html#id2916148">Opportunistic Locking Overview</a></dt></dl></dd><dt><a href="locking.html#id2916856">Samba Opportunistic Locking Control</a></dt><dd><dl><dt><a href="locking.html#id2916978">Example Configuration</a></dt></dl></dd><dt><a href="locking.html#id2917407">MS Windows Opportunistic Locking and Caching Controls</a></dt><dd><dl><dt><a href="locking.html#id2917632">Workstation Service Entries</a></dt><dt><a href="locking.html#id2917660">Server Service Entries</a></dt></dl></dd><dt><a href="locking.html#id2917740">Persistent Data Corruption</a></dt><dt><a href="locking.html#id2917769">Common Errors</a></dt><dd><dl><dt><a href="locking.html#id2917850">locking.tdb Error Messages</a></dt><dt><a href="locking.html#id2917884">Problems Saving Files in MS Office on Windows XP</a></dt><dt><a href="locking.html#id2917904">Long Delays Deleting Files Over Network with XP SP1</a></dt></dl></dd><dt><a href="locking.html#id2917935">Additional Reading</a></dt></dl></div><p> +One area that causes trouble for many network administrators is locking. +The extent of the problem is readily evident from searches over the Internet. +</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2915945"></a>Features and Benefits</h2></div></div><div></div></div><p> Samba provides all the same locking semantics that MS Windows clients expect -and that MS Windows NT4 / 200x servers provide also. +and that MS Windows NT4/200x servers also provide. </p><p> The term <span class="emphasis"><em>locking</em></span> has exceptionally broad meaning and covers a range of functions that are all categorized under this one term. </p><p> Opportunistic locking is a desirable feature when it can enhance the -perceived performance of applications on a networked client. However, the -opportunistic locking protocol is not robust, and therefore can -encounter problems when invoked beyond a simplistic configuration, or -on extended, slow, or faulty networks. In these cases, operating +perceived performance of applications on a networked client. However, the +opportunistic locking protocol is not robust and, therefore, can +encounter problems when invoked beyond a simplistic configuration or +on extended slow or faulty networks. In these cases, operating system management of opportunistic locking and/or recovering from repetitive errors can offset the perceived performance advantage that it is intended to provide. </p><p> The MS Windows network administrator needs to be aware that file and record -locking semantics (behaviour) can be controlled either in Samba or by way of registry +locking semantics (behavior) can be controlled either in Samba or by way of registry settings on the MS Windows client. </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -Sometimes it is necessary to disable locking control settings BOTH on the Samba +Sometimes it is necessary to disable locking control settings on both the Samba server as well as on each MS Windows client! -</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2908589"></a>Discussion</h2></div></div><div></div></div><p> -There are two types of locking which need to be performed by a SMB server. -The first is <span class="emphasis"><em>record locking</em></span> which allows a client to lock -a range of bytes in a open file. The second is the <span class="emphasis"><em>deny modes</em></span> +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2916001"></a>Discussion</h2></div></div><div></div></div><p> +There are two types of locking that need to be performed by an SMB server. +The first is <span class="emphasis"><em>record locking</em></span> that allows a client to lock +a range of bytes in a open file. The second is the <span class="emphasis"><em>deny modes</em></span> that are specified when a file is open. </p><p> Record locking semantics under UNIX are very different from record locking under -Windows. Versions of Samba before 2.2 have tried to use the native fcntl() unix +Windows. Versions of Samba before 2.2 have tried to use the native fcntl() UNIX system call to implement proper record locking between different Samba clients. -This can not be fully correct due to several reasons. The simplest is the fact +This cannot be fully correct for several reasons. The simplest is the fact that a Windows client is allowed to lock a byte range up to 2^32 or 2^64, -depending on the client OS. The unix locking only supports byte ranges up to 2^31. +depending on the client OS. The UNIX locking only supports byte ranges up to 2^31. So it is not possible to correctly satisfy a lock request above 2^31. There are many more differences, too many to be listed here. </p><p> Samba 2.2 and above implements record locking completely independent of the -underlying unix system. If a byte range lock that the client requests happens -to fall into the range 0-2^31, Samba hands this request down to the UNIX system. -All other locks can not be seen by unix anyway. -</p><p> -Strictly an SMB server should check for locks before every read and write call on -a file. Unfortunately with the way fcntl() works this can be slow and may over-stress -the <b class="command">rpc.lockd</b>. It is also almost always unnecessary as clients are supposed to -independently make locking calls before reads and writes anyway if locking is -important to them. By default Samba only makes locking calls when explicitly asked -to by a client, but if you set <a class="indexterm" name="id2908656"></a><i class="parameter"><tt>strict locking</tt></i> = yes then it -will make lock checking calls on every read and write. -</p><p> -You can also disable byte range locking completely using <a class="indexterm" name="id2908676"></a><i class="parameter"><tt>locking</tt></i> = no. -This is useful for those shares that don't support locking or don't need it -(such as cdroms). In this case Samba fakes the return codes of locking calls to -tell clients that everything is OK. +underlying UNIX system. If a byte range lock that the client requests happens +to fall into the range of 0-2^31, Samba hands this request down to the UNIX system. +All other locks cannot be seen by UNIX, anyway. +</p><p> +Strictly speaking, an SMB server should check for locks before every read and write call on +a file. Unfortunately with the way fcntl() works, this can be slow and may overstress +the <b class="command">rpc.lockd</b>. This is almost always unnecessary as clients are supposed to +independently make locking calls before reads and writes if locking is +important to them. By default, Samba only makes locking calls when explicitly asked +to by a client, but if you set <a class="indexterm" name="id2916068"></a><i class="parameter"><tt>strict locking</tt></i> = yes, it +will make lock checking calls on <span class="emphasis"><em>every</em></span> read and write call. +</p><p> +You can also disable byte range locking completely by using +<a class="indexterm" name="id2916093"></a><i class="parameter"><tt>locking</tt></i> = no. +This is useful for those shares that do not support locking or do not need it +(such as CDROMs). In this case, Samba fakes the return codes of locking calls to +tell clients that everything is okay. </p><p> The second class of locking is the <span class="emphasis"><em>deny modes</em></span>. These are set by an application when it opens a file to determine what types of access should be allowed simultaneously with its open. A client may ask for <tt class="constant">DENY_NONE</tt>, <tt class="constant">DENY_READ</tt>, -<tt class="constant">DENY_WRITE</tt> or <tt class="constant">DENY_ALL</tt>. There are also special compatibility +<tt class="constant">DENY_WRITE</tt>, or <tt class="constant">DENY_ALL</tt>. There are also special compatibility modes called <tt class="constant">DENY_FCB</tt> and <tt class="constant">DENY_DOS</tt>. -</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2908732"></a>Opportunistic Locking Overview</h3></div></div><div></div></div><p> +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2916148"></a>Opportunistic Locking Overview</h3></div></div><div></div></div><p> Opportunistic locking (Oplocks) is invoked by the Windows file system -(as opposed to an API) via registry entries (on the server AND client) +(as opposed to an API) via registry entries (on the server and the client) for the purpose of enhancing network performance when accessing a file residing on a server. Performance is enhanced by caching the file -locally on the client which allows: +locally on the client that allows: </p><div class="variablelist"><dl><dt><span class="term">Read-ahead:</span></dt><dd><p> - The client reads the local copy of the file, eliminating network latency + The client reads the local copy of the file, eliminating network latency. </p></dd><dt><span class="term">Write caching:</span></dt><dd><p> - The client writes to the local copy of the file, eliminating network latency + The client writes to the local copy of the file, eliminating network latency. </p></dd><dt><span class="term">Lock caching:</span></dt><dd><p> - The client caches application locks locally, eliminating network latency + The client caches application locks locally, eliminating network latency. </p></dd></dl></div><p> The performance enhancement of oplocks is due to the opportunity of -exclusive access to the file - even if it is opened with deny-none - +exclusive access to the file even if it is opened with deny-none because Windows monitors the file's status for concurrent access from other processes. -</p><div class="variablelist"><p class="title"><b>Windows defines 4 kinds of Oplocks:</b></p><dl><dt><span class="term">Level1 Oplock:</span></dt><dd><p> +</p><div class="variablelist"><p class="title"><b>Windows defines 4 kinds of Oplocks:</b></p><dl><dt><span class="term">Level1 Oplock</span></dt><dd><p> The redirector sees that the file was opened with deny none (allowing concurrent access), verifies that no other process is accessing the file, checks that oplocks are enabled, then grants deny-all/read-write/exclusive - access to the file. The client now performs + access to the file. The client now performs operations on the cached local file. </p><p> If a second process attempts to open the file, the open - is deferred while the redirector "breaks" the original - oplock. The oplock break signals the caching client to + is deferred while the redirector “<span class="quote">breaks</span>” the original + oplock. The oplock break signals the caching client to write the local file back to the server, flush the - local locks, and discard read-ahead data. The break is + local locks and discard read-ahead data. The break is then complete, the deferred open is granted, and the multiple processes can enjoy concurrent file access as dictated by mandatory or byte-range locking options. @@ -99,130 +100,130 @@ other processes. file with a share mode other than deny-none, then the second process is granted limited or no access, despite the oplock break. - </p></dd><dt><span class="term">Level2 Oplock:</span></dt><dd><p> - Performs like a level1 oplock, except caching is only + </p></dd><dt><span class="term">Level2 Oplock</span></dt><dd><p> + Performs like a Level1 oplock, except caching is only operative for reads. All other operations are performed on the server disk copy of the file. - </p></dd><dt><span class="term">Filter Oplock:</span></dt><dd><p> - Does not allow write or delete file access - </p></dd><dt><span class="term">Batch Oplock:</span></dt><dd><p> - Manipulates file openings and closings - allows caching - of file attributes + </p></dd><dt><span class="term">Filter Oplock</span></dt><dd><p> + Does not allow write or delete file access. + </p></dd><dt><span class="term">Batch Oplock</span></dt><dd><p> + Manipulates file openings and closings and allows caching + of file attributes. </p></dd></dl></div><p> An important detail is that oplocks are invoked by the file system, not -an application API. Therefore, an application can close an oplocked -file, but the file system does not relinquish the oplock. When the +an application API. Therefore, an application can close an oplocked +file, but the file system does not relinquish the oplock. When the oplock break is issued, the file system then simply closes the file in preparation for the subsequent open by the second process. </p><p> -<span class="emphasis"><em>Opportunistic Locking</em></span> is actually an improper name for this feature. +<span class="emphasis"><em>Opportunistic locking</em></span> is actually an improper name for this feature. The true benefit of this feature is client-side data caching, and oplocks is merely a notification mechanism for writing data back to the -networked storage disk. The limitation of opportunistic locking is the +networked storage disk. The limitation of opportunistic locking is the reliability of the mechanism to process an oplock break (notification) -between the server and the caching client. If this exchange is faulty -(usually due to timing out for any number of reasons) then the +between the server and the caching client. If this exchange is faulty +(usually due to timing out for any number of reasons), then the client-side caching benefit is negated. </p><p> The actual decision that a user or administrator should consider is -whether it is sensible to share amongst multiple users data that will -be cached locally on a client. In many cases the answer is no. +whether it is sensible to share among multiple users data that will +be cached locally on a client. In many cases the answer is no. Deciding when to cache or not cache data is the real question, and thus -"opportunistic locking" should be treated as a toggle for client-side -caching. Turn it "ON" when client-side caching is desirable and -reliable. Turn it "OFF" when client-side caching is redundant, -unreliable, or counter-productive. +“<span class="quote">opportunistic locking</span>” should be treated as a toggle for client-side +caching. Turn it “<span class="quote">on</span>” when client-side caching is desirable and +reliable. Turn it “<span class="quote">off</span>” when client-side caching is redundant, +unreliable or counter-productive. </p><p> -Opportunistic locking is by default set to "on" by Samba on all +Opportunistic locking is by default set to “<span class="quote">on</span>” by Samba on all configured shares, so careful attention should be given to each case to determine if the potential benefit is worth the potential for delays. The following recommendations will help to characterize the environment where opportunistic locking may be effectively configured. </p><p> -Windows Opportunistic Locking is a lightweight performance-enhancing -feature. It is not a robust and reliable protocol. Every -implementation of Opportunistic Locking should be evaluated as a -tradeoff between perceived performance and reliability. Reliability -decreases as each successive rule above is not enforced. Consider a +Windows opportunistic locking is a lightweight performance-enhancing +feature. It is not a robust and reliable protocol. Every +implementation of opportunistic locking should be evaluated as a +tradeoff between perceived performance and reliability. Reliability +decreases as each successive rule above is not enforced. Consider a share with oplocks enabled, over a wide area network, to a client on a South Pacific atoll, on a high-availability server, serving a -mission-critical multi-user corporate database, during a tropical -storm. This configuration will likely encounter problems with oplocks. +mission-critical multi-user corporate database during a tropical +storm. This configuration will likely encounter problems with oplocks. </p><p> Oplocks can be beneficial to perceived client performance when treated -as a configuration toggle for client-side data caching. If the data +as a configuration toggle for client-side data caching. If the data caching is likely to be interrupted, then oplock usage should be -reviewed. Samba enables opportunistic locking by default on all -shares. Careful attention should be given to the client usage of -shared data on the server, the server network reliability, and the +reviewed. Samba enables opportunistic locking by default on all +shares. Careful attention should be given to the client usage of +shared data on the server, the server network reliability and the opportunistic locking configuration of each share. -n mission critical high availability environments, data integrity is -often a priority. Complex and expensive configurations are implemented +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. </p><p> 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. +interruption than other platforms because it is dependent 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 +correctly from a transport connection loss, therefore, most applications +will experience some sort of interruption at worst, abort and require restarting. </p><p> 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 +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 with the client writing data to the file server +real-time, the failover will provide the data on disk as it existed at the time of the disconnect. </p><p> -In mission critical high availability environments, careful attention -should be given to opportunistic locking. Ideally, comprehensive +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. -</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2909061"></a>Exclusively Accessed Shares</h4></div></div><div></div></div><p> +</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2916474"></a>Exclusively Accessed Shares</h4></div></div><div></div></div><p> Opportunistic locking is most effective when it is confined to shares that are exclusively accessed by a single user, or by only one user at -a time. Because the true value of opportunistic locking is the local +a time. Because the true value of opportunistic locking is the local client caching of data, any operation that interrupts the caching mechanism will cause a delay. </p><p> Home directories are the most obvious examples of where the performance benefit of opportunistic locking can be safely realized. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2909086"></a>Multiple-Accessed Shares or Files</h4></div></div><div></div></div><p> +</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2916498"></a>Multiple-Accessed Shares or Files</h4></div></div><div></div></div><p> As each additional user accesses a file in a share with opportunistic locking enabled, the potential for delays and resulting perceived poor -performance increases. When multiple users are accessing a file on a +performance increases. When multiple users are accessing a file on a share that has oplocks enabled, the management impact of sending and -receiving oplock breaks, and the resulting latency while other clients -wait for the caching client to flush data, offset the performance gains +receiving oplock breaks and the resulting latency while other clients +wait for the caching client to flush data offset the performance gains of the caching user. </p><p> As each additional client attempts to access a file with oplocks set, the potential performance improvement is negated and eventually results in a performance bottleneck. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2909115"></a>UNIX or NFS Client Accessed Files</h4></div></div><div></div></div><p> +</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2916527"></a>UNIX or NFS Client-Accessed Files</h4></div></div><div></div></div><p> Local UNIX and NFS clients access files without a mandatory -file locking mechanism. Thus, these client platforms are incapable of +file-locking mechanism. Thus, these client platforms are incapable of initiating an oplock break request from the server to a Windows client that has a file cached. Local UNIX or NFS file access can therefore write to a file that has been cached by a Windows client, which exposes the file to likely data corruption. </p><p> If files are shared between Windows clients, and either local UNIX -or NFS users, then turn opportunistic locking off. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2909141"></a>Slow and/or Unreliable Networks</h4></div></div><div></div></div><p> +or NFS users, turn opportunistic locking off. +</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2916553"></a>Slow and/or Unreliable Networks</h4></div></div><div></div></div><p> The biggest potential performance improvement for opportunistic locking occurs when the client-side caching of reads and writes delivers the most differential over sending those reads and writes over the wire. This is most likely to occur when the network is extremely slow, -congested, or distributed (as in a WAN). However, network latency also -has a very high impact on the reliability of the oplock break +congested, or distributed (as in a WAN). However, network latency also +has a high impact on the reliability of the oplock break mechanism, and thus increases the likelihood of encountering oplock problems that more than offset the potential perceived performance gain. Of course, if an oplock break never has to be sent, then this is @@ -231,112 +232,112 @@ the most advantageous scenario to utilize opportunistic locking. If the network is slow, unreliable, or a WAN, then do not configure opportunistic locking if there is any chance of multiple users regularly opening the same file. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2909174"></a>Multi-User Databases</h4></div></div><div></div></div><p> -Multi-user databases clearly pose a risk due to their very nature - +</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2916586"></a>Multi-User Databases</h4></div></div><div></div></div><p> +Multi-user databases clearly pose a risk due to their very nature they are typically heavily accessed by numerous users at random -intervals. Placing a multi-user database on a share with opportunistic +intervals. Placing a multi-user database on a share with opportunistic locking enabled will likely result in a locking management bottleneck -on the Samba server. Whether the database application is developed +on the Samba server. Whether the database application is developed in-house or a commercially available product, ensure that the share has opportunistic locking disabled. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2909204"></a>PDM Data Shares</h4></div></div><div></div></div><p> -Process Data Management (PDM) applications such as IMAN, Enovia, and -Clearcase, are increasing in usage with Windows client platforms, and -therefore SMB data stores. PDM applications manage multi-user -environments for critical data security and access. The typical PDM +</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2916611"></a>PDM Data Shares</h4></div></div><div></div></div><p> +Process Data Management (PDM) applications such as IMAN, Enovia and +Clearcase are increasing in usage with Windows client platforms, and +therefore SMB datastores. PDM applications manage multi-user +environments for critical data security and access. The typical PDM environment is usually associated with sophisticated client design -applications that will load data locally as demanded. In addition, the +applications that will load data locally as demanded. In addition, the PDM application will usually monitor the data-state of each client. In this case, client-side data caching is best left to the local -application and PDM server to negotiate and maintain. It is +application and PDM server to negotiate and maintain. It is appropriate to eliminate the client OS from any caching tasks, and the server from any oplock management, by disabling opportunistic locking on the share. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2909231"></a>Beware of Force User</h4></div></div><div></div></div><p> -Samba includes an <tt class="filename">smb.conf</tt> parameter called <a class="indexterm" name="id2909250"></a><i class="parameter"><tt>force user</tt></i> that changes +</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2916637"></a>Beware of Force User</h4></div></div><div></div></div><p> +Samba includes an <tt class="filename">smb.conf</tt> parameter called <a class="indexterm" name="id2916656"></a><i class="parameter"><tt>force user</tt></i> that changes the user accessing a share from the incoming user to whatever user is -defined by the smb.conf variable. If opportunistic locking is enabled +defined by the smb.conf variable. If opportunistic locking is enabled on a share, the change in user access causes an oplock break to be sent -to the client, even if the user has not explicitly loaded a file. In +to the client, even if the user has not explicitly loaded a file. In cases where the network is slow or unreliable, an oplock break can -become lost without the user even accessing a file. This can cause +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. </p><p> Avoid the combination of the following: </p><div class="itemizedlist"><ul type="disc"><li><p> - <a class="indexterm" name="id2909286"></a><i class="parameter"><tt>force user</tt></i> in the <tt class="filename">smb.conf</tt> share configuration. + <a class="indexterm" name="id2916692"></a><i class="parameter"><tt>force user</tt></i> in the <tt class="filename">smb.conf</tt> share configuration. </p></li><li><p> Slow or unreliable networks </p></li><li><p> - Opportunistic Locking Enabled - </p></li></ul></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2909323"></a>Advanced Samba Opportunistic Locking Parameters</h4></div></div><div></div></div><p> + Opportunistic locking enabled + </p></li></ul></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2916729"></a>Advanced Samba Opportunistic Locking Parameters</h4></div></div><div></div></div><p> 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 +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: -<a class="indexterm" name="id2909340"></a><i class="parameter"><tt>oplock break wait time</tt></i>, -<a class="indexterm" name="id2909355"></a><i class="parameter"><tt>oplock contention limit</tt></i>. +likely cause problems. The parameters are: +<a class="indexterm" name="id2916746"></a><i class="parameter"><tt>oplock break wait time</tt></i>, +<a class="indexterm" name="id2916760"></a><i class="parameter"><tt>oplock contention limit</tt></i>. </p><p> -For most users, administrators, and environments, if these parameters +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." +The Samba SWAT help text for both parameters reads: “<span class="quote">Do not change +this parameter unless you have read and understood the Samba oplock code.</span>” This is good advice. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2909382"></a>Mission Critical High Availability</h4></div></div><div></div></div><p> -In mission critical high availability environments, data integrity is -often a priority. Complex and expensive configurations are implemented +</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2916790"></a>Mission-Critical High-Availability</h4></div></div><div></div></div><p> +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. </p><p> 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. +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 +correctly from a transport connection loss, therefore, most applications +will experience some sort of interruption at worst, abort and require restarting. </p><p> 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 +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. </p><p> -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 +In mission-critical high-availability environments, careful attention +should be given to opportunistic locking. Ideally, comprehensive +testing should be done with all effected applications with oplocks enabled and disabled. -</p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2909449"></a>Samba Opportunistic Locking Control</h2></div></div><div></div></div><p> -Opportunistic Locking is a unique Windows file locking feature. It is +</p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2916856"></a>Samba Opportunistic Locking Control</h2></div></div><div></div></div><p> +Opportunistic locking is a unique Windows file locking feature. It is not really file locking, but is included in most discussions of Windows file locking, so is considered a de facto locking feature. -Opportunistic Locking is actually part of the Windows client file -caching mechanism. It is not a particularly robust or reliable feature +Opportunistic locking is actually part of the Windows client file +caching mechanism. It is not a particularly robust or reliable feature when implemented on the variety of customized networks that exist in enterprise computing. </p><p> -Like Windows, Samba implements Opportunistic Locking as a server-side -component of the client caching mechanism. Because of the lightweight +Like Windows, Samba implements opportunistic locking as a server-side +component of the client caching mechanism. Because of the lightweight nature of the Windows feature design, effective configuration of -Opportunistic Locking requires a good understanding of its limitations, +opportunistic locking requires a good understanding of its limitations, and then applying that understanding when configuring data access for each particular customized network and client usage state. </p><p> Opportunistic locking essentially means that the client is allowed to download and cache a file on their hard drive while making changes; if a second client wants to access the -file, the first client receives a break and must synchronise the file back to the server. +file, the first client receives a break and must synchronize the file back to the server. This can give significant performance gains in some cases; some programs insist on -synchronising the contents of the entire file back to the server for a single change. +synchronizing the contents of the entire file back to the server for a single change. </p><p> -Level1 Oplocks (aka just plain "oplocks") is another term for opportunistic locking. +Level1 Oplocks (also known as just plain “<span class="quote">oplocks</span>”) is another term for opportunistic locking. </p><p> Level2 Oplocks provides opportunistic locking for a file that will be treated as <span class="emphasis"><em>read only</em></span>. Typically this is used on files that are read-only or @@ -344,16 +345,16 @@ on files that the client has no initial intention to write to at time of opening </p><p> Kernel Oplocks are essentially a method that allows the Linux kernel to co-exist with Samba's oplocked files, although this has provided better integration of MS Windows network -file locking with the under lying OS, SGI IRIX and Linux are the only two OS's that are -oplock aware at this time. +file locking with the underlying OS, SGI IRIX and Linux are the only two OSs that are +oplock-aware at this time. </p><p> Unless your system supports kernel oplocks, you should disable oplocks if you are accessing the same files from both UNIX/Linux and SMB clients. Regardless, oplocks should always be disabled if you are sharing a database file (e.g., Microsoft Access) between -multiple clients, as any break the first client receives will affect synchronisation of +multiple clients, as any break the first client receives will affect synchronization of the entire file (not just the single record), which will result in a noticeable performance impairment and, more likely, problems accessing the database in the first place. Notably, -Microsoft Outlook's personal folders (*.pst) react very badly to oplocks. If in doubt, +Microsoft Outlook's personal folders (*.pst) react quite badly to oplocks. If in doubt, disable oplocks and tune your system from that point. </p><p> If client-side caching is desirable and reliable on your network, you will benefit from @@ -364,14 +365,14 @@ of your client sending oplock breaks and will instead want to disable oplocks fo </p><p> Another factor to consider is the perceived performance of file access. If oplocks provide no measurable speed benefit on your network, it might not be worth the hassle of dealing with them. -</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2909569"></a>Example Configuration</h3></div></div><div></div></div><p> -In the following we examine two distinct aspects of Samba locking controls. -</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2909582"></a>Disabling Oplocks</h4></div></div><div></div></div><p> +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2916978"></a>Example Configuration</h3></div></div><div></div></div><p> +In the following section we examine two distinct aspects of Samba locking controls. +</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2916991"></a>Disabling Oplocks</h4></div></div><div></div></div><p> You can disable oplocks on a per-share basis with the following: </p><p> </p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[acctdata]</tt></i></td></tr><tr><td><i class="parameter"><tt>oplocks = False</tt></i></td></tr><tr><td><i class="parameter"><tt>level2 oplocks = False</tt></i></td></tr></table><p> </p><p> -The default oplock type is Level1. Level2 Oplocks are enabled on a per-share basis +The default oplock type is Level1. Level2 oplocks are enabled on a per-share basis in the <tt class="filename">smb.conf</tt> file. </p><p> Alternately, you could disable oplocks on a per-file basis within the share: @@ -379,69 +380,67 @@ Alternately, you could disable oplocks on a per-file basis within the share: </p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/</tt></i></td></tr></table><p> </p><p> If you are experiencing problems with oplocks as apparent from Samba's log entries, -you may want to play it safe and disable oplocks and level2 oplocks. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2909679"></a>Disabling Kernel OpLocks</h4></div></div><div></div></div><p> -Kernel OpLocks is an <tt class="filename">smb.conf</tt> parameter that notifies Samba (if +you may want to play it safe and disable oplocks and Level2 oplocks. +</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2917088"></a>Disabling Kernel Oplocks</h4></div></div><div></div></div><p> +Kernel oplocks is an <tt class="filename">smb.conf</tt> parameter that notifies Samba (if the UNIX kernel has the capability to send a Windows client an oplock break) when a UNIX process is attempting to open the file that is -cached. This parameter addresses sharing files between UNIX and -Windows with Oplocks enabled on the Samba server: the UNIX process +cached. This parameter addresses sharing files between UNIX and +Windows with oplocks enabled on the Samba server: the UNIX process can open the file that is Oplocked (cached) by the Windows client and the smbd process will not send an oplock break, which exposes the file -to the risk of data corruption. If the UNIX kernel has the ability to +to the risk of data corruption. If the UNIX kernel has the ability to send an oplock break, then the kernel oplocks parameter enables Samba -to send the oplock break. Kernel oplocks are enabled on a per-server +to send the oplock break. Kernel oplocks are enabled on a per-server basis in the <tt class="filename">smb.conf</tt> file. </p><p> - </p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>kernel oplocks = yes</tt></i></td></tr></table><p> -The default is "no". +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>kernel oplocks = yes</tt></i></td></tr></table><p> +The default is no. </p><p> -Veto OpLocks is an <tt class="filename">smb.conf</tt> parameter that identifies specific files for -which Oplocks are disabled. When a Windows client opens a file that +Veto opLocks is an <tt class="filename">smb.conf</tt> parameter that identifies specific files for +which oplocks are disabled. When a Windows client opens a file that has been configured for veto oplocks, the client will not be granted the oplock, and all operations will be executed on the original file on -disk instead of a client-cached file copy. By explicitly identifying -files that are shared with UNIX processes, and disabling oplocks for +disk instead of a client-cached file copy. By explicitly identifying +files that are shared with UNIX processes and disabling oplocks for those files, the server-wide Oplock configuration can be enabled to allow Windows clients to utilize the performance benefit of file -caching without the risk of data corruption. Veto Oplocks can be +caching without the risk of data corruption. Veto Oplocks can be enabled on a per-share basis, or globally for the entire server, in the -<tt class="filename">smb.conf</tt> file: +<tt class="filename">smb.conf</tt> file as shown in <link linkend="far1">. </p><p> -</p><div class="example"><a name="id2909772"></a><p class="title"><b>Example 14.1. Share with some files oplocked</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>veto oplock files = /filename.htm/*.txt/</tt></i></td></tr><tr><td> </td></tr><tr><td><i class="parameter"><tt>[share_name]</tt></i></td></tr><tr><td><i class="parameter"><tt>veto oplock files = /*.exe/filename.ext/</tt></i></td></tr></table></div><p> +</p><div class="example"><a name="far1"></a><p class="title"><b>Example 14.1. Share with some files oplocked</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>veto oplock files = /filename.htm/*.txt/</tt></i></td></tr><tr><td> </td></tr><tr><td><i class="parameter"><tt>[share_name]</tt></i></td></tr><tr><td><i class="parameter"><tt>veto oplock files = /*.exe/filename.ext/</tt></i></td></tr></table></div><p> </p><p> - <a class="indexterm" name="id2909826"></a><i class="parameter"><tt>oplock break wait time</tt></i> is an <tt class="filename">smb.conf</tt> parameter that adjusts the time -interval for Samba to reply to an oplock break request. Samba -recommends "DO NOT CHANGE THIS PARAMETER UNLESS YOU HAVE READ AND -UNDERSTOOD THE SAMBA OPLOCK CODE." Oplock Break Wait Time can only be -configured globally in the <tt class="filename">smb.conf</tt> file: +<a class="indexterm" name="id2917246"></a><i class="parameter"><tt>oplock break wait time</tt></i> is an <tt class="filename">smb.conf</tt> parameter +that adjusts the time interval for Samba to reply to an oplock break request. Samba recommends: +“<span class="quote">Do not change this parameter unless you have read and understood the Samba oplock code.</span>” +Oplock break Wait Time can only be configured globally in the <tt class="filename">smb.conf</tt> file as shown below. </p><p> </p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>oplock break wait time = 0 (default)</tt></i></td></tr></table><p> </p><p> <span class="emphasis"><em>Oplock break contention limit</em></span> is an <tt class="filename">smb.conf</tt> parameter that limits the response of the Samba server to grant an oplock if the configured -number of contending clients reaches the limit specified by the -parameter. Samba recommends "DO NOT CHANGE THIS PARAMETER UNLESS YOU -HAVE READ AND UNDERSTOOD THE SAMBA OPLOCK CODE." Oplock Break -Contention Limit can be enable on a per-share basis, or globally for -the entire server, in the <tt class="filename">smb.conf</tt> file: -</p><p> - </p><div class="example"><a name="id2909930"></a><p class="title"><b>Example 14.2. </b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>oplock break contention limit = 2 (default)</tt></i></td></tr><tr><td> </td></tr><tr><td><i class="parameter"><tt>[share_name]</tt></i></td></tr><tr><td><i class="parameter"><tt>oplock break contention limit = 2 (default)</tt></i></td></tr></table></div><p> -</p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2909983"></a>MS Windows Opportunistic Locking and Caching Controls</h2></div></div><div></div></div><p> +number of contending clients reaches the limit specified by the parameter. Samba recommends +“<span class="quote">Do not change this parameter unless you have read and understood the Samba oplock code.</span>” +Oplock break Contention Limit can be enable on a per-share basis, or globally for +the entire server, in the <tt class="filename">smb.conf</tt> file as shown in <link linkend="far3">. +</p><p> +</p><div class="example"><a name="far3"></a><p class="title"><b>Example 14.2. Configuration with oplock break contention limit</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>oplock break contention limit = 2 (default)</tt></i></td></tr><tr><td> </td></tr><tr><td><i class="parameter"><tt>[share_name]</tt></i></td></tr><tr><td><i class="parameter"><tt>oplock break contention limit = 2 (default)</tt></i></td></tr></table></div><p> +</p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2917407"></a>MS Windows Opportunistic Locking and Caching Controls</h2></div></div><div></div></div><p> There is a known issue when running applications (like Norton Anti-Virus) on a Windows 2000/ XP workstation computer that can affect any application attempting to access shared database files across a network. This is a result of a default setting configured in the Windows 2000/XP -operating system known as <span class="emphasis"><em>Opportunistic Locking</em></span>. When a workstation +operating system known as <span class="emphasis"><em>opportunistic locking</em></span>. When a workstation attempts to access shared data files located on another Windows 2000/XP computer, the Windows 2000/XP operating system will attempt to increase performance by locking the files and caching information locally. When this occurs, the application is unable to -properly function, which results in an <span class="errorname">Access Denied</span> +properly function, which results in an “<span class="quote">Access Denied</span>” error message being displayed during network operations. </p><p> All Windows operating systems in the NT family that act as database servers for data files (meaning that data files are stored there and accessed by other Windows PCs) may need to have opportunistic locking disabled in order to minimize the risk of data file corruption. -This includes Windows 9x/Me, Windows NT, Windows 200x and Windows XP. +This includes Windows 9x/Me, Windows NT, Windows 200x, and Windows XP. </p><p> If you are using a Windows NT family workstation in place of a server, you must also disable opportunistic locking (oplocks) on that workstation. For example, if you use a @@ -453,7 +452,7 @@ The major difference is the location in the Windows registry where the values fo oplocks are entered. Instead of the LanManServer location, the LanManWorkstation location may be used. </p><p> -You can verify (or change or add, if necessary) this Registry value using the Windows +You can verify (change or add, if necessary) this registry value using the Windows Registry Editor. When you change this registry value, you will have to reboot the PC to ensure that the new setting goes into effect. </p><p> @@ -491,75 +490,75 @@ request opportunistic locks on a remote file. To disable oplocks, the value of The EnableOplocks value configures Windows-based servers (including Workstations sharing files) to allow or deny opportunistic locks on local files. </p></div><p> -To force closure of open oplocks on close or program exit EnableOpLockForceClose must be set to 1. +To force closure of open oplocks on close or program exit, EnableOpLockForceClose must be set to 1. </p><p> -An illustration of how level II oplocks work: +An illustration of how Level2 oplocks work: </p><div class="itemizedlist"><ul type="disc"><li><p> - Station 1 opens the file, requesting oplock. + Station 1 opens the file requesting oplock. </p></li><li><p> Since no other station has the file open, the server grants station 1 exclusive oplock. </p></li><li><p> - Station 2 opens the file, requesting oplock. + Station 2 opens the file requesting oplock. </p></li><li><p> - Since station 1 has not yet written to the file, the server asks station 1 to Break - to Level II Oplock. + Since station 1 has not yet written to the file, the server asks station 1 to break + to Level2 oplock. </p></li><li><p> Station 1 complies by flushing locally buffered lock information to the server. </p></li><li><p> - Station 1 informs the server that it has Broken to Level II Oplock (alternatively, + Station 1 informs the server that it has Broken to Level2 Oplock (alternately, station 1 could have closed the file). </p></li><li><p> - The server responds to station 2's open request, granting it level II oplock. - Other stations can likewise open the file and obtain level II oplock. + The server responds to station 2's open request, granting it Level2 oplock. + Other stations can likewise open the file and obtain Level2 oplock. </p></li><li><p> Station 2 (or any station that has the file open) sends a write request SMB. The server returns the write response. </p></li><li><p> - The server asks all stations that have the file open to Break to None, meaning no + The server asks all stations that have the file open to break to none, meaning no station holds any oplock on the file. Because the workstations can have no cached writes or locks at this point, they need not respond to the break-to-none advisory; all they need do is invalidate locally cashed read-ahead data. - </p></li></ul></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2910208"></a>Workstation Service Entries</h3></div></div><div></div></div><pre class="programlisting"> + </p></li></ul></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2917632"></a>Workstation Service Entries</h3></div></div><div></div></div><pre class="programlisting"> \HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\LanmanWorkstation\Parameters UseOpportunisticLocking REG_DWORD 0 or 1 Default: 1 (true) </pre><p> -Indicates whether the redirector should use opportunistic-locking (oplock) performance +This indicates whether the redirector should use opportunistic-locking (oplock) performance enhancement. This parameter should be disabled only to isolate problems. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2910237"></a>Server Service Entries</h3></div></div><div></div></div><pre class="programlisting"> +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2917660"></a>Server Service Entries</h3></div></div><div></div></div><pre class="programlisting"> \HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\LanmanServer\Parameters EnableOplocks REG_DWORD 0 or 1 Default: 1 (true) </pre><p> -Specifies whether the server allows clients to use oplocks on files. Oplocks are a +This specifies whether the server allows clients to use oplocks on files. Oplocks are a significant performance enhancement, but have the potential to cause lost cached -data on some networks, particularly wide-area networks. +data on some networks, particularly wide area networks. </p><pre class="programlisting"> MinLinkThroughput REG_DWORD 0 to infinite bytes per second Default: 0 </pre><p> -Specifies the minimum link throughput allowed by the server before it disables +This specifies the minimum link throughput allowed by the server before it disables raw and opportunistic locks for this connection. </p><pre class="programlisting"> MaxLinkDelay REG_DWORD 0 to 100,000 seconds Default: 60 </pre><p> -Specifies the maximum time allowed for a link delay. If delays exceed this number, +This specifies the maximum time allowed for a link delay. If delays exceed this number, the server disables raw I/O and opportunistic locking for this connection. </p><pre class="programlisting"> OplockBreakWait REG_DWORD 10 to 180 seconds Default: 35 </pre><p> -Specifies the time that the server waits for a client to respond to an oplock break +This specifies the time that the server waits for a client to respond to an oplock break request. Smaller values can allow detection of crashed clients more quickly but can potentially cause loss of cached data. -</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2910317"></a>Persistent Data Corruption</h2></div></div><div></div></div><p> +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2917740"></a>Persistent Data Corruption</h2></div></div><div></div></div><p> If you have applied all of the settings discussed in this chapter but data corruption problems -and other symptoms persist, here are some additional things to check out: +and other symptoms persist, here are some additional things to check out. </p><p> We have credible reports from developers that faulty network hardware, such as a single faulty network card, can cause symptoms similar to read caching and data corruption. @@ -568,70 +567,69 @@ rebuild the data files in question. This involves creating a new data file with same definition as the file to be rebuilt and transferring the data from the old file to the new one. There are several known methods for doing this that can be found in our Knowledge Base. -</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2910345"></a>Common Errors</h2></div></div><div></div></div><p> -In some sites locking problems surface as soon as a server is installed, in other sites +</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2917769"></a>Common Errors</h2></div></div><div></div></div><p> +In some sites, locking problems surface as soon as a server is installed; in other sites locking problems may not surface for a long time. Almost without exception, when a locking problem does surface it will cause embarrassment and potential data corruption. </p><p> -Over the past few years there have been a number of complaints on the samba mailing lists -that have claimed that samba caused data corruption. Three causes have been identified +Over the past few years there have been a number of complaints on the Samba mailing lists +that have claimed that Samba caused data corruption. Three causes have been identified so far: </p><div class="itemizedlist"><ul type="disc"><li><p> Incorrect configuration of opportunistic locking (incompatible with the application - being used. This is a VERY common problem even where MS Windows NT4 or MS Windows 200x - based servers were in use. It is imperative that the software application vendors' + being used. This is a common problem even where MS Windows NT4 or MS Windows + 200x-based servers were in use. It is imperative that the software application vendors' instructions for configuration of file locking should be followed. If in doubt, disable oplocks on both the server and the client. Disabling of all forms of file caching on the MS Windows client may be necessary also. </p></li><li><p> - Defective network cards, cables, or HUBs / Switched. This is generally a more - prevalent factor with low cost networking hardware, though occasionally there - have been problems with incompatibilities in more up market hardware also. + Defective network cards, cables, or HUBs/Switched. This is generally a more + prevalent factor with low cost networking hardware, although occasionally there + have also been problems with incompatibilities in more up-market hardware. </p></li><li><p> - There have been some random reports of samba log files being written over data - files. This has been reported by very few sites (about 5 in the past 3 years) - and all attempts to reproduce the problem have failed. The Samba-Team has been - unable to catch this happening and thus has NOT been able to isolate any particular - cause. Considering the millions of systems that use samba, for the sites that have - been affected by this as well as for the Samba-Team this is a frustrating and - a vexing challenge. If you see this type of thing happening please create a bug - report on https://bugzilla.samba.org without delay. Make sure that you give as much - information as you possibly can to help isolate the cause and to allow reproduction - of the problem (an essential step in problem isolation and correction). - </p></li></ul></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2910419"></a>locking.tdb error messages</h3></div></div><div></div></div><p> + There have been some random reports of Samba log files being written over data + files. This has been reported by very few sites (about five in the past three years) + and all attempts to reproduce the problem have failed. The Samba Team has been + unable to catch this happening and thus has not been able to isolate any particular + cause. Considering the millions of systems that use Samba, for the sites that have + been affected by this as well as for the Samba Team this is a frustrating and + a vexing challenge. If you see this type of thing happening, please create a bug + report on Samba <ulink url="https://bugzilla.samba.org">Bugzilla</ulink> without delay. + Make sure that you give as much information as you possibly can help isolate the + cause and to allow replication of the problem (an essential step in problem isolation and correction). + </p></li></ul></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2917850"></a>locking.tdb Error Messages</h3></div></div><div></div></div><p> “<span class="quote"> - We are seeing lots of errors in the samba logs like: -</span>” -</p><pre class="programlisting"> + We are seeing lots of errors in the Samba logs, like: +<pre class="programlisting"> tdb(/usr/local/samba_2.2.7/var/locks/locking.tdb): rec_read bad magic 0x4d6f4b61 at offset=36116 -</pre><p> -“<span class="quote"> +</pre> + What do these mean? </span>” </p><p> - Corrupted tdb. Stop all instances of smbd, delete locking.tdb, restart smbd. - </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2910456"></a>Problems saving files in MS Office on Windows XP</h3></div></div><div></div></div><p>This is a bug in Windows XP. More information can be - found in <a href="http://support.microsoft.com/?id=812937" target="_top">Microsoft Knowledge Base article 812937</a>.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2910479"></a>Long delays deleting files over network with XP SP1</h3></div></div><div></div></div><p>“<span class="quote">It sometimes takes approximately 35 seconds to delete files over the network after XP SP1 has been applied</span>”</p><p>This is a bug in Windows XP. More information can be - found in <a href="http://support.microsoft.com/?id=811492" target="_top"> - Microsoft Knowledge Base article 811492</a>.</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2910511"></a>Additional Reading</h2></div></div><div></div></div><p> + This error indicated a corrupted tdb. Stop all instances of smbd, delete locking.tdb, and restart smbd. + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2917884"></a>Problems Saving Files in MS Office on Windows XP</h3></div></div><div></div></div><p>This is a bug in Windows XP. More information can be + found in <ulink url="http://support.microsoft.com/?id=812937">Microsoft Knowledge Base article 812937.</ulink></p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2917904"></a>Long Delays Deleting Files Over Network with XP SP1</h3></div></div><div></div></div><p>“<span class="quote">It sometimes takes approximately 35 seconds to delete files over the network after XP SP1 has been applied.</span>”</p><p>This is a bug in Windows XP. More information can be found in <ulink url="http://support.microsoft.com/?id=811492"> + Microsoft Knowledge Base article 811492.</ulink></p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2917935"></a>Additional Reading</h2></div></div><div></div></div><p> You may want to check for an updated version of this white paper on our Web site from time to time. Many of our white papers are updated as information changes. For those papers, -the Last Edited date is always at the top of the paper. +the last edited date is always at the top of the paper. </p><p> Section of the Microsoft MSDN Library on opportunistic locking: </p><p> Opportunistic Locks, Microsoft Developer Network (MSDN), Windows Development > Windows Base Services > Files and I/O > SDK Documentation > File Storage > File Systems > About File Systems > Opportunistic Locks, Microsoft Corporation. -<a href="http://msdn.microsoft.com/library/en-us/fileio/storage_5yk3.asp" target="_top">http://msdn.microsoft.com/library/en-us/fileio/storage_5yk3.asp</a> +<ulink url="http://msdn.microsoft.com/library/en-us/fileio/storage_5yk3.asp">http://msdn.microsoft.com/library/en-us/fileio/storage_5yk3.asp</ulink> </p><p> -Microsoft Knowledge Base Article Q224992 "Maintaining Transactional Integrity with OPLOCKS", -Microsoft Corporation, April 1999, <a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224992" target="_top">http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224992</a>. + Microsoft Knowledge Base Article Q224992 “<span class="quote">Maintaining Transactional Integrity +with OPLOCKS</span>”, +Microsoft Corporation, April 1999, <ulink url="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224992">http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224992</ulink>. </p><p> -Microsoft Knowledge Base Article Q296264 "Configuring Opportunistic Locking in Windows 2000", -Microsoft Corporation, April 2001, <a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q296264" target="_top">http://support.microsoft.com/default.aspx?scid=kb;en-us;Q296264</a>. +Microsoft Knowledge Base Article Q296264 “<span class="quote">Configuring Opportunistic Locking in Windows 2000</span>”, +Microsoft Corporation, April 2001, <ulink url="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q296264">http://support.microsoft.com/default.aspx?scid=kb;en-us;Q296264</ulink>. </p><p> -Microsoft Knowledge Base Article Q129202 "PC Ext: Explanation of Opportunistic Locking on Windows NT", - Microsoft Corporation, April 1995, <a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q129202" target="_top">http://support.microsoft.com/default.aspx?scid=kb;en-us;Q129202</a>. -</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="AccessControls.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="securing-samba.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 13. File, Directory and Share Access Controls </td><td width="20%" align="center"><a accesskey="h" href="samba-doc.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 15. Securing Samba</td></tr></table></div></body></html> +Microsoft Knowledge Base Article Q129202 “<span class="quote">PC Ext: Explanation of Opportunistic Locking on Windows NT</span>”, +Microsoft Corporation, April 1995, <ulink url="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q129202">http://support.microsoft.com/default.aspx?scid=kb;en-us;Q129202</ulink>. +</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="AccessControls.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="securing-samba.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 13. File, Directory and Share Access Controls </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 15. Securing Samba</td></tr></table></div></body></html> |