docs/htmldocs/using_samba/appb_02.html

   1 <HTML>
   2 <HEAD>
   3 <TITLE>
   4 [Appendix B] B.2 Samba Tuning</title><META NAME="DC.title" CONTENT=""><META NAME="DC.creator" CONTENT=""><META NAME="DC.publisher" CONTENT="O'Reilly &amp; Associates, Inc."><META NAME="DC.date" CONTENT="1999-11-05T21:42:03Z"><META NAME="DC.type" CONTENT="Text.Monograph"><META NAME="DC.format" CONTENT="text/html" SCHEME="MIME"><META NAME="DC.source" CONTENT="" SCHEME="ISBN"><META NAME="DC.language" CONTENT="en-US"><META NAME="generator" CONTENT="Jade 1.1/O'Reilly DocBook 3.0 to HTML 4.0"></head>
   5 <BODY BGCOLOR="#FFFFFF" TEXT="#000000" link="#990000" vlink="#0000CC">
   6 <table BORDER="0" CELLPADDING="0" CELLSPACING="0" width="90%">
   7 <tr>
   8 <td width="25%" valign="TOP">
   9 <img hspace=10 vspace=10 src="gifs/samba.s.gif"
  10 alt="Using Samba" align=left valign=top border=0>
  11 </td>
  12 <td height="105" valign="TOP">
  13 <br>
  14 <H2>Using Samba</H2>
  15 <font size="-1">
  16 Robert Eckstein, David Collier-Brown, Peter Kelly
  17 <br>1st Edition November 1999
  18 <br>1-56592-449-5, Order Number: 4495
  19 <br>416 pages, $34.95
  20 </font>
  21 <p> <a href="http://www.oreilly.com/catalog/samba/">Buy the hardcopy</a>
  22 <p><a href="index.html">Table of Contents</a>
  23 </td>
  24 </tr>
  25 </table>
  26 <hr size=1 noshade>
  27 <!--sample chapter begins -->
  28
  29 <center>
  30 <DIV CLASS="htmlnav">
  31 <TABLE WIDTH="515" BORDER="0" CELLSPACING="0" CELLPADDING="0">
  32 <TR>
  33 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="172">
  34 <A CLASS="sect1" HREF="appb_01.html" TITLE="B.1 A Simple Benchmark">
  35 <IMG SRC="gifs/txtpreva.gif" ALT="Previous: B.1 A Simple Benchmark" BORDER="0"></a></td><TD ALIGN="CENTER" VALIGN="TOP" WIDTH="171">
  36 <B>
  37 <FONT FACE="ARIEL,HELVETICA,HELV,SANSERIF" SIZE="-1">
  38 <A CLASS="appendix" REL="up" HREF="appb_01.html" TITLE="B. Samba Performance Tuning">
  39 Appendix B<br>
  40 Samba Performance Tuning</a></font></b></td><TD ALIGN="RIGHT" VALIGN="TOP" WIDTH="172">
  41 <A CLASS="sect1" HREF="appb_03.html" TITLE="B.3 Sizing Samba Servers">
  42 <IMG SRC="gifs/txtnexta.gif" ALT="Next: B.3 Sizing Samba Servers" BORDER="0"></a></td></tr></table>&nbsp;<hr noshade size=1></center>
  43 </div>
  44 <blockquote>
  45 <div>
  46 <H2 CLASS="sect1">
  47 <A CLASS="title" NAME="appb-50295">
  48 B.2 Samba Tuning</a></h2><P CLASS="para">That being said, let's discuss how you can take an already fast networking package and make it even faster.</p><DIV CLASS="sect2">
  49 <H3 CLASS="sect2">
  50 <A CLASS="title" NAME="appb-pgfId-948325">
  51 B.2.1 Benchmarking</a></h3><P CLASS="para">Benchmarking is an arcane and somewhat black art, but the level of expertise needed for simple performance tuning is fairly low. Since the Samba server's goal in life is to transfer files, we will examine only throughput, not response time to particular events, under the benchmarking microscope. After all, it's relatively easy to measure file transfer speed, and Samba doesn't suffer too badly from response-time problems that would require more sophisticated techniques. </p><P CLASS="para">
  52 Our basic strategy for this work will be:</p><UL CLASS="itemizedlist">
  53 <LI CLASS="listitem">
  54 <P CLASS="para">
  55 <A CLASS="listitem" NAME="appb-pgfId-948328">
  56 </a>Find a reasonably-sized file to copy and a program that reports on copy speeds, such as <I CLASS="filename">
  57 smbclient</i>.</p></li><LI CLASS="listitem">
  58 <P CLASS="para">
  59 <A CLASS="listitem" NAME="appb-pgfId-948329">
  60 </a>Find a quiet (or typical) time to do the test.</p></li><LI CLASS="listitem">
  61 <P CLASS="para">
  62 <A CLASS="listitem" NAME="appb-pgfId-948330">
  63 </a>Pre-run each test a few times to preload buffers.</p></li><LI CLASS="listitem">
  64 <P CLASS="para">
  65 <A CLASS="listitem" NAME="appb-pgfId-948331">
  66 </a>Run tests several times and watch for unusual results.</p></li><LI CLASS="listitem">
  67 <P CLASS="para">
  68 <A CLASS="listitem" NAME="appb-pgfId-948332">
  69 </a>Record each run in detail.</p></li><LI CLASS="listitem">
  70 <P CLASS="para">
  71 <A CLASS="listitem" NAME="appb-pgfId-948333">
  72 </a>Compare the average of the valid runs to expected values.</p></li></ul><P CLASS="para">
  73 After establishing a baseline using this method, we can adjust a single parameter and do the measurements all over again. An empty table for your tests is provided at the end of this chapter.</p></div><DIV CLASS="sect2">
  74 <H3 CLASS="sect2">
  75 <A CLASS="title" NAME="appb-pgfId-948336">
  76 B.2.2 Things to Tweak</a></h3><P CLASS="para">
  77 There are literally thousands of Samba setting combinations that you can use in search of that perfect server. Those of us with lives outside of system administration, however, can narrow down the number of options to those listed in this section, which are the most likely to affect overall throughput. They are presented  roughly in order of impact.</p><DIV CLASS="sect3">
  78 <H4 CLASS="sect3">
  79 <A CLASS="title" NAME="appb-pgfId-948339">
  80 B.2.2.1 Log level</a></h4><P CLASS="para">This is an obvious one. Increasing the logging level (<CODE CLASS="literal">log</code> <CODE CLASS="literal">
  81 level</code> or <CODE CLASS="literal">
  82 debug</code> <CODE CLASS="literal">
  83 level</code> configuration options) is a good way to debug a problem, unless you happen to be searching for a performance problem! As mentioned in <a href="ch04_01.html"><b>Chapter 4, <CITE CLASS="chapter">Disk Shares</cite></b></a>, Samba produces a ton of debugging messages at level 3 and above, and writing them to disk or syslog is a slow operation. In our <I CLASS="filename">
  84 smbclient/ftp</i> tests, raising the log level from 0 to 3 cut the untuned <CODE CLASS="literal">
  85 get</code> <CODE CLASS="literal">
  86 speed</code> from 645.3 to 622.2KB/s, or roughly 5 percent. Higher log levels were even worse.</p></div><DIV CLASS="sect3">
  87 <H4 CLASS="sect3">
  88 <A CLASS="title" NAME="appb-pgfId-948342">
  89 B.2.2.2 Socket options</a></h4><P CLASS="para">
  90 The next thing to look at are the <CODE CLASS="literal">
  91 socket</code> <CODE CLASS="literal">
  92 options</code> configuration options. These are really host system tuning options, but they're set on a per-connection basis, and can be reset by Samba on the sockets it employs by adding <CODE CLASS="literal">
  93 socket</code> <CODE CLASS="literal">
  94 options</code> <CODE CLASS="literal">
  95 =</code> <CODE CLASS="literal">
  96 option</code> to the <CODE CLASS="literal">
  97 [global]</code> section of your <I CLASS="filename">
  98 smb.conf </i>file. Not all of these options are supported by all vendors; check your vendor's manual pages on <I CLASS="function">
  99 setsockopt </i>(1) or <I CLASS="function">
 100 socket </i>(5) for details.</p><P CLASS="para">
 101 The main options are:</p><DL CLASS="variablelist">
 102 <DT CLASS="term">
 103 <CODE CLASS="literal">
 104 TCP_NODELAY</code></dt><DD CLASS="listitem">
 105 <P CLASS="para">
 106 Have the server send as many packets as necessary to keep delay low. This is used on telnet connections to give good response time, and is used&nbsp;- somewhat counter-intuitively&nbsp;- to get good speed even when doing small requests or when acknowledgments are delayed (as seems to occur with Microsoft TCP/IP). This is worth a 30-50 percent speedup by itself. Incidentally, in Samba 2.0.4, <CODE CLASS="literal">
 107 socket</code> <CODE CLASS="literal">
 108 options</code> <CODE CLASS="literal">
 109 =</code> <CODE CLASS="literal">
 110 TCP_NODELAY</code> became the default value for that option.</p></dd><DT CLASS="term">
 111 <CODE CLASS="literal">
 112 IPTOS_LOWDELAY</code></dt><DD CLASS="listitem">
 113 <P CLASS="para">
 114 This is another option that trades off throughput for lower delay, but which affects routers and other systems, not the server. All the IPTOS options are new; they're not supported by all operating systems and routers. If they are supported, set <CODE CLASS="literal">
 115 IPTOS_LOWDELAY</code> whenever you set <CODE CLASS="literal">
 116 TCP_NODELAY</code>.</p></dd><DT CLASS="term">
 117 <CODE CLASS="literal">
 118 SO_SNDBUF</code> <CODE CLASS="literal">
 119 and</code> <CODE CLASS="literal">
 120 SO_RCVBUF</code></dt><DD CLASS="listitem">
 121 <P CLASS="para">
 122 The send and receive buffers can often be the reset to a value higher than that of the operating system. This yields a marginal increase of speed (until it reaches a point of diminishing returns).  </p></dd><DT CLASS="term">
 123 <CODE CLASS="literal">
 124 SO_KEEPALIVE</code></dt><DD CLASS="listitem">
 125 <P CLASS="para">
 126 This initiates a periodic (four-hour) check to see if the client has disappeared. Expired connections are addressed somewhat better with Samba's <CODE CLASS="literal">
 127 keepalive</code> and <CODE CLASS="literal">
 128 dead</code> <CODE CLASS="literal">
 129 time</code> options. All three eventually arrange to close dead connections, returning unused memory and process-table entries to the operating system.</p></dd></dl><P CLASS="para">
 130 There are several other socket options you might look at, (e.g., <CODE CLASS="literal">
 131 SO_SNDLOWAT</code>), but they vary in availability from vendor to vendor. You probably want to look at <CITE CLASS="citetitle">
 132 TCP/IP Illustrated</cite> if you're interested in exploring more of these options for performance tuning with Samba.</p></div><DIV CLASS="sect3">
 133 <H4 CLASS="sect3">
 134 <A CLASS="title" NAME="appb-pgfId-948370">
 135 B.2.2.3 read raw and write raw</a></h4><P CLASS="para">These are important performance configuration options; they enable Samba to use large reads and writes to the network, of up to 64KB in a single SMB request. They also require the largest SMB packet structures, <CODE CLASS="literal">
 136 SMBreadraw</code> and <CODE CLASS="literal">
 137 SMBwriteraw</code>, from which the options take their names. Note that this is not the same as a Unix <EM CLASS="emphasis">
 138 raw read</em>. This Unix term usually refers to reading disks without using the files system, quite a different sense from the one described here for Samba.</p><P CLASS="para">
 139 In the past, some client programs failed if you tried to use <CODE CLASS="literal">
 140 read</code> <CODE CLASS="literal">
 141 raw</code>. As far as we know, no client suffers from this problem any more. Read and write raw default to <CODE CLASS="literal">
 142 yes</code>, and should be left on unless you find you have one of the buggy clients.</p></div><DIV CLASS="sect3">
 143 <H4 CLASS="sect3">
 144 <A CLASS="title" NAME="appb-pgfId-948374">
 145 B.2.2.4 Opportunistic locking</a></h4><P CLASS="para">Opportunistic locks, or <EM CLASS="emphasis">
 146 oplocks</em>, allow clients to cache files locally, improving performance on the order of 30 percent. This option is now enabled by default. For read-only files, the <CODE CLASS="literal">
 147 fake</code> <CODE CLASS="literal">
 148 oplocks</code> provides the same functionality without actually doing any caching. If you have files that cannot be cached, <EM CLASS="emphasis">
 149 oplocks</em> can be turned off.</p><P CLASS="para">
 150 Database files should never be cached, nor should any files that are updated both on the server and the client and whose changes must be immediately visible. For these files, the <CODE CLASS="literal">
 151 veto</code> <CODE CLASS="literal">
 152 oplock</code> <CODE CLASS="literal">
 153 files</code> option allows you to specify a list of individual files or a pattern containing wildcards to avoid caching. <EM CLASS="emphasis">
 154 oplocks</em> can be turned off on a share-by-share basis if you have large groups of files you don't want cached on clients. See <a href="ch05_01.html"><b>Chapter 5, <CITE CLASS="chapter">Browsing and Advanced Disk Shares</cite></b></a>, for more information on opportunistic locks.</p></div><DIV CLASS="sect3">
 155 <H4 CLASS="sect3">
 156 <A CLASS="title" NAME="appb-pgfId-948378">
 157 B.2.2.5 IP packet size (MTU)</a></h4><P CLASS="para">Networks generally set a limit to the size of an individual transmission or packet This is called the Maximum Segment Size, or if the packet header size is included, the Maximum Transport Unit (MTU). This MTU is not set by Samba, but Samba needs to use a <CODE CLASS="literal">
 158 max</code> <CODE CLASS="literal">
 159 xmit</code> (write size) bigger than the MTU, or throughput will be reduced. This is discussed in further detail in the following note. The MTU is normally preset to 1500 bytes on an Ethernet and 4098 bytes on FDDI. In general, having it too low cuts throughput, and having it too high causes a sudden performance dropoff due to fragmentation and retransmissions.</p><P CLASS="para">
 160 If you are communicating over a router, some systems will assume the router is a serial link (e.g., a T1) and set the MTU to more or less 536 bytes. Windows 95 makes this mistake, which causes nearby clients to perform well, but clients on the other side of the router to be noticeably slower. If the client makes the opposite error and uses a large MTU on a link which demands a small one, the packets will be broken up into fragments. This slows transfers slightly, and any networking errors will cause multiple fragments to be retransmitted, which slows Samba significantly. Fortunately, you can modify the Windows MTU size to prevent either error. To understand this in more detail, see "The Windows 95 Networking Frequently Asked Questions (FAQ)" at <A CLASS="systemitem.url" HREF="http://www.stanford.edu/~llurch/win95netbugs/faq.html">
 161 http://www.stanford.edu/~llurch/win95netbugs/faq.html</a>, which explains how to override the Windows MTU and Window Size.</p></div><DIV CLASS="sect3">
 162 <H4 CLASS="sect3">
 163 <A CLASS="title" NAME="appb-19919">
 164 <a name="b226"></a>
 165 B.2.2.6 The TCP receive window</a></h4><P CLASS="para">TCP/IP works by breaking down data into small packets that can be transmitted from one machine to another. When each packet is transmitted, it contains a checksum that allows the receiver to check the packet data for potential errors in transmission. Theoretically, when a packet is received and verified, an acknowledgment packet should be sent back to the sender that essentially says, "Everything arrived intact: please continue."</p><P CLASS="para">
 166 In order to keep things moving, however, TCP accepts a range (window) of packets that allows a sender to keep transmitting without having to wait for an acknowledgment of every single packet. (It can then bundle a group of acknowledgments and transmit them back to the sender at the same time.) In other words, this receive window is the number of bytes that the sender can transmit before it has to stop and wait for a receiver's acknowledgment. Like the MTU, it is automatically set based on the type of connection. Having the window too small causes a lot of unnecessary waiting for acknowledgment messages. Various operating systems set moderate buffer sizes on a per-socket basis to keep one program from hogging all the memory.</p><P CLASS="para">
 167 The buffer sizes are assigned in bytes, such as <CODE CLASS="literal">
 168 SO_SNDBUF=8192</code> in the <CODE CLASS="literal">
 169 socket</code> <CODE CLASS="literal">
 170 options</code> line. Thus, an example <CODE CLASS="literal">
 171 socket</code> <CODE CLASS="literal">
 172 options</code> configuration option is: </p><PRE CLASS="programlisting">
 173 <CODE CLASS="literal">socket</code> <CODE CLASS="literal">options</code> <CODE CLASS="literal">=</code> <CODE CLASS="literal">SO_SNDBUF=8192</code> </pre><P CLASS="para">
 174 Normally, one tries to set these socket options higher than the default: 4098 in SunOS 4.1.3 and SVR4, and 8192-16384 in AIX, Solaris, and BSD. 16384 has been suggested as a good starting point: in a non-Samba test mentioned in Stevens' book, it yielded a 40 percent improvement. You'll need to experiment, because performance will fall off again if you set the sizes too high. This is illustrated in <A CLASS="xref" HREF="appb_02.html#appb-34738">
 175 Figure B.1</a>, a test done on a particular Linux system.  </p><H4 CLASS="figure">
 176 <A CLASS="title" NAME="appb-34738">
 177 Figure B.1: SO_SNDBUF size and performance</a></h4><IMG CLASS="graphic" SRC="figs/sam.ab01.gif" ALT="Figure B.1"><P CLASS="para">
 178 Setting the socket options <CODE CLASS="literal">
 179 O_SNDBUF</code> and <CODE CLASS="literal">
 180 SO_RCVBUF</code> to less than the default is inadvisable. Setting them higher improves performance, up to a network-specific limit. However, once you exceed that limit, performance will abruptly level off.</p></div><DIV CLASS="sect3">
 181 <H4 CLASS="sect3">
 182 <A CLASS="title" NAME="appb-pgfId-960372">
 183 B.2.2.7 max xmit</a></h4><P CLASS="para">In Samba, the option that is directly related with the MTU and window size is <CODE CLASS="literal">
 184 max</code> <CODE CLASS="literal">
 185 xmit</code>. This option sets the largest block of data Samba will try to write at any one time. It's sometimes known as the <I CLASS="firstterm">
 186 write size</i>, although that is not the name of the Samba configuration option.</p><P CLASS="para">
 187 Because the percentage of each block required for overhead falls as the blocks get larger, max xmit is conventionally set as large as possible. It defaults to the protocol's upper limit, which is 64 kilobytes. The smallest value that doesn't cause significant slowdowns is 2048. If it is set low enough, it will limit the largest packet size that Samba will be able to negotiate. This can be used to simulate a small MTU if you need to test an unreliable network connection. However, such a test should not be used in production for reducing the effective MTU.</p></div><DIV CLASS="sect3">
 188 <H4 CLASS="sect3">
 189 <A CLASS="title" NAME="appb-pgfId-948396">
 190 B.2.2.8 read size</a></h4><P CLASS="para">If <CODE CLASS="literal">
 191 max</code> <CODE CLASS="literal">
 192 xmit</code> is commonly called the write size, you'd expect <CODE CLASS="literal">
 193 read</code> <CODE CLASS="literal">
 194 size</code> to be the maximum amount of data that Samba would want to read from the client via the network. Actually, it's not. In fact, it's an option to trigger <I CLASS="firstterm">
 195 write ahead</i>. This means that if Samba gets behind reading from the disk and writing to the network (or vice versa) by the specified amount, it will start overlapping network writes with disk reads (or vice versa).</p><P CLASS="para">
 196 The read size doesn't have a big performance effect on Unix, unless you set its value quite small. At that point, it causes a detectable slowdown. For this reason, it defaults to 2048 and can't be set lower than 1024.</p></div><DIV CLASS="sect3">
 197
 198 <H4 CLASS="sect3">
 199 <A CLASS="title" NAME="appb-pgfId-950907">
 200 B.2.2.9 read prediction </a></h4>
 201
 202 <P CLASS="para">Besides being counterintuitive, this option is also
 203 obsolete. It enables Samba to read ahead on files opened read only by the
 204 clients. The option is disabled in Samba 2.0 (and late 1.9) because it
 205 interferes with opportunistic locking.</p>
 206
 207 <H4 CLASS="sect3">
 208 <A CLASS="title" NAME="appb-pgfId-950907-add1">
 209 B.2.2.10 write cache size </a></h4>
 210
 211 <P CLASS="para">
 212 This parameter was introduced in Samba 2.0.7 to allow tuning the
 213 write-size of RAID disks, as well as allowing general caching of
 214 writes on machines with lots of memory but slow disks.</p>
 215
 216 <p> It specifies in bytes the size of a per-file write cache that
 217 Samba will create for an oplocked file. This can improve performance
 218 significantly by causing writes to be done in large
 219 chunk sizes. </p>
 220
 221 <p> Up to 10 write caches can be active simultaneously per smbd, each of
 222 the specified size, allocated to the first 10 oplocked files. As with
 223 other filesystem caches, crashing before the data is written can corrupt
 224 files. </P>
 225
 226 <p> Setting <CODE CLASS="literal"> sync always </CODE> will override the
 227 write caching, and setting <CODE CLASS="literal">strict sync</CODE> will
 228 allow Windows clients to override it.  Alas, Windows Explorer defaults
 229 to setting the sync bit, so setting <CODE CLASS="literal">strict sync</CODE>
 230 can be a big performance hit.</p>
 231
 232 <p> As it's new, we haven't many reports on the performance increase, and
 233 merely suspect it will be considerable.</p>
 234 </div></div><DIV CLASS="sect2">
 235
 236
 237
 238 <H3 CLASS="sect2">
 239 <A CLASS="title" NAME="appb-pgfId-948407">
 240 B.2.3 Other Samba Options</a></h3><P CLASS="para">The following Samba options will affect performance if they're set incorrectly, much like the debug level. They're mentioned here so you will know what to look out for:</p><DL CLASS="variablelist">
 241 <DT CLASS="term">
 242 <CODE CLASS="literal">hide files</code></dt><DD CLASS="listitem">
 243 <P CLASS="para">
 244 Providing a pattern to identify files hidden by the Windows client <CODE CLASS="literal">
 245 hide</code> <CODE CLASS="literal">
 246 files</code> will result in any file matching the pattern being passed to the client with the DOS hidden attribute set. It requires a pattern match per file when listing directories, and slows the server noticeably.</p></dd><DT CLASS="term">
 247 <CODE CLASS="literal">
 248 lpq cache time</code></dt><DD CLASS="listitem">
 249 <P CLASS="para">If your <CODE CLASS="literal">
 250 lpq</code> (printer queue contents) command takes a long time to complete, you should increase <CODE CLASS="literal">
 251 lpq</code> <CODE CLASS="literal">
 252 cache</code> <CODE CLASS="literal">
 253 time</code> to a value higher than the actual time required for <CODE CLASS="literal">
 254 lpq</code> to execute, so as to keep Samba from starting a new query when one's already running. The default is 10 seconds, which is reasonable.</p></dd><DT CLASS="term">
 255 <CODE CLASS="literal">
 256 strict locking</code></dt><DD CLASS="listitem">
 257 <P CLASS="para">Setting the <CODE CLASS="literal">
 258 strict</code> <CODE CLASS="literal">
 259 locking</code> option causes Samba to check for locks on every access, not just when asked to by the client. The option is primarily a bug-avoidance feature, and can prevent ill-behaved DOS and Windows applications from corrupting shared files. However, it is slow and should typically be avoided.</p></dd><DT CLASS="term">
 260 <CODE CLASS="literal">
 261 strict sync</code></dt><DD CLASS="listitem">
 262 <P CLASS="para">Setting <CODE CLASS="literal">
 263 strict</code> <CODE CLASS="literal">
 264 sync</code> will cause Samba to write each packet to disk and wait for the write to complete whenever the client sets the sync bit in a packet. Windows 98 Explorer sets the bit in all packets transmitted, so if you turn this on, anyone with Windows 98 will think Samba servers are horribly slow.</p></dd><DT CLASS="term">
 265 <CODE CLASS="literal">
 266 sync always</code></dt><DD CLASS="listitem">
 267 <P CLASS="para">Setting <CODE CLASS="literal">
 268 sync</code> <CODE CLASS="literal">
 269 always</code> causes Samba to flush every write to disk. This is good if your server crashes constantly, but the performance costs are immense. SMB servers normally use oplocks and automatic reconnection to avoid the ill effects of crashes, so setting this option is not normally necessary.</p></dd><DT CLASS="term">
 270 <CODE CLASS="literal">wide links</code></dt><DD CLASS="listitem">
 271 <P CLASS="para">
 272 Turning off <CODE CLASS="literal">
 273 wide</code> <CODE CLASS="literal">
 274 links</code> prevents Samba from following symbolic links in one file share to files that are not in the share. It is turned on by default, since following links in Unix is not a security problem. Turning it off requires extra processing on every file open. If you do turn off wide links, be sure to turn on <CODE CLASS="literal">
 275 getwd</code> <CODE CLASS="literal">
 276 cache</code> to cache some of the required data.</p><P CLASS="para">
 277 There is also a <CODE CLASS="literal">
 278 follow</code> <CODE CLASS="literal">
 279 symlinks</code> option that can be turned off to prevent following any symbolic links at all. However, this option does not pose a performance problem.</p></dd><DT CLASS="term">
 280 <CODE CLASS="literal">getwd cache</code></dt><DD CLASS="listitem">
 281 <P CLASS="para">
 282 This option caches the path to the current directory, avoiding long tree-walks to discover it. It's a nice performance improvement on a printer server or if you've turned off <CODE CLASS="literal">
 283 wide</code> <CODE CLASS="literal">
 284 links</code>.</p></dd></dl></div><DIV CLASS="sect2">
 285 <H3 CLASS="sect2">
 286 <A CLASS="title" NAME="appb-pgfId-948430">
 287 B.2.4 Our Recommendations </a></h3><P CLASS="para">Here's an <I CLASS="filename">
 288 smb.conf</i> file that incorporates the recommended performance enhancements so far. Comments have been added on the right side.</p><PRE CLASS="programlisting">
 289 [global]
 290         log level = 1                      # Default is 0
 291         socket options = TCP_NODELAY IPTOS_LOWDELAY
 292         read raw = yes                     # Default
 293         write raw = yes                    # Default
 294         oplocks = yes                      # Default
 295         max xmit = 65535                   # Default
 296         dead time = 15                     # Default is 0
 297         getwd cache = yes
 298         lpq cache = 30
 299 [okplace]
 300         veto oplock files = this/that/theotherfile
 301 [badplace]
 302         oplocks = no</pre></div></div></blockquote>
 303 <div>
 304 <center>
 305 <hr noshade size=1><TABLE WIDTH="515" BORDER="0" CELLSPACING="0" CELLPADDING="0">
 306 <TR>
 307 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="172">
 308 <A CLASS="sect1" HREF="appb_01.html" TITLE="B.1 A Simple Benchmark">
 309 <IMG SRC="gifs/txtpreva.gif" ALT="Previous: B.1 A Simple Benchmark" BORDER="0"></a></td><TD ALIGN="CENTER" VALIGN="TOP" WIDTH="171">
 310 <A CLASS="book" HREF="index.html" TITLE="">
 311 <IMG SRC="gifs/txthome.gif" ALT="" BORDER="0"></a></td><TD ALIGN="RIGHT" VALIGN="TOP" WIDTH="172">
 312 <A CLASS="sect1" HREF="appb_03.html" TITLE="B.3 Sizing Samba Servers">
 313 <IMG SRC="gifs/txtnexta.gif" ALT="Next: B.3 Sizing Samba Servers" BORDER="0"></a></td></tr><TR>
 314 <TD ALIGN="LEFT" VALIGN="TOP" WIDTH="172">
 315 B.1 A Simple Benchmark</td><TD ALIGN="CENTER" VALIGN="TOP" WIDTH="171">
 316 <A CLASS="index" HREF="inx.html" TITLE="Book Index">
 317 <IMG SRC="gifs/index.gif" ALT="Book Index" BORDER="0"></a></td><TD ALIGN="RIGHT" VALIGN="TOP" WIDTH="172">
 318 B.3 Sizing Samba Servers</td></tr></table><hr noshade size=1></center>
 319 </div>
 320
 321 <!-- End of sample chapter -->
 322 <CENTER>
 323 <FONT SIZE="1" FACE="Verdana, Arial, Helvetica">
 324 <A HREF="http://www.oreilly.com/">
 325 <B>O'Reilly Home</B></A> <B> | </B>
 326 <A HREF="http://www.oreilly.com/sales/bookstores">
 327 <B>O'Reilly Bookstores</B></A> <B> | </B>
 328 <A HREF="http://www.oreilly.com/order_new/">
 329 <B>How to Order</B></A> <B> | </B>
 330 <A HREF="http://www.oreilly.com/oreilly/contact.html">
 331 <B>O'Reilly Contacts<BR></B></A>
 332 <A HREF="http://www.oreilly.com/international/">
 333 <B>International</B></A> <B> | </B>
 334 <A HREF="http://www.oreilly.com/oreilly/about.html">
 335 <B>About O'Reilly</B></A> <B> | </B>
 336 <A HREF="http://www.oreilly.com/affiliates.html">
 337 <B>Affiliated Companies</B></A><p>
 338 <EM>&copy; 1999, O'Reilly &amp; Associates, Inc.</EM>
 339 </FONT>
 340 </CENTER>
 341 </BODY>
 342 </html>