Attachment 8923 Details for Bug 9906 – assorted doc patches from master for 4.0

[patch] assorted doc patches from master for 4.0

doc-4.0.patch (text/plain), 42.09 KB, created by Andrew Bartlett on 2013-05-27 11:45:53 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Andrew Bartlett

Created: 2013-05-27 11:45:53 UTC

Size: 42.09 KB

patch

obsolete

>From 69735a73b0baf021a2f395ae3c7915655201ef6f Mon Sep 17 00:00:00 2001
>From: Andrew Bartlett <abartlet@samba.org>
>Date: Tue, 21 May 2013 17:49:55 +1000
>Subject: [PATCH 1/4] docs: Remove out of date and unmaintained Speed page
> from the HOWTO
>
>Reviewed-by: Jeremy Allison <jra@samba.org>
>(cherry picked from commit fa8e760882ea389f8c94d6dfdc7386b0295974d1)
>---
> docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml | 327 --------------------------------
> docs-xml/Samba3-HOWTO/index.xml         |   2 -
> 2 files changed, 329 deletions(-)
> delete mode 100644 docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml
>
>diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml b/docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml
>deleted file mode 100644
>index 18a15ae..0000000
>--- a/docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml
>+++ /dev/null
>@@ -1,327 +0,0 @@
>-<?xml version="1.0" encoding="iso-8859-1"?>
>-<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
>-<chapter id="speed">
>-
>-<chapterinfo>
>-	<author>
>-		<firstname>Paul</firstname><surname>Cochrane</surname>
>-		<affiliation>
>-			<orgname>Dundee Limb Fitting Centre</orgname>
>-			<address><email>paulc@dth.scot.nhs.uk</email></address>
>-		</affiliation>
>-	</author>
>-	&author.jelmer;
>-	&author.jht;
>-</chapterinfo>
>-
>-<title>Samba Performance Tuning</title>
>-
>-<sect1>
>-<title>Comparisons</title>
>-
>-<para>
>-The Samba server uses TCP to talk to the client, so if you are
>-trying to see if it performs well, you should really compare it to
>-programs that use the same protocol. The most readily available
>-programs for file transfer that use TCP are ftp or another TCP-based
>-SMB server.
>-</para>
>-
>-<para>
>-If you want to test against something like an NT or Windows for Workgroups server, then
>-you will have to disable all but TCP on either the client or
>-server. Otherwise, you may well be using a totally different protocol
>-(such as NetBEUI) and comparisons may not be valid.
>-</para>
>-
>-<para>
>-Generally, you should find that Samba performs similarly to ftp at raw
>-transfer speed. It should perform quite a bit faster than NFS,
>-although this depends on your system.
>-</para>
>-
>-<para>
>-Several people have done comparisons between Samba and Novell, NFS, or
>-Windows NT. In some cases Samba performed the best, in others the worst. I
>-suspect the biggest factor is not Samba versus some other system, but the
>-hardware and drivers used on the various systems. Given similar
>-hardware, Samba should certainly be competitive in speed with other
>-systems.
>-</para>
>-
>-</sect1>
>-
>-<sect1>
>-<title>Socket Options</title>
>-
>-<para>
>-There are a number of socket options that can greatly affect the
>-performance of a TCP-based server like Samba.
>-</para>
>-
>-<para>
>-The socket options that Samba uses are settable both on the command
>-line with the <option>-O</option> option and in the &smb.conf; file.
>-</para>
>-
>-<para>
>-The <smbconfoption name="socket options"/> section of the &smb.conf; manual page describes how
>-to set these and gives recommendations.
>-</para>
>-
>-<para>
>-Getting the socket options correct can make a big difference to your
>-performance, but getting them wrong can degrade it by just as
>-much. The correct settings are very dependent on your local network.
>-</para>
>-
>-<para>
>-The socket option TCP_NODELAY is the one that seems to make the biggest single difference
>-for most networks. Many people report that adding
>-<smbconfoption name="socket options">TCP_NODELAY</smbconfoption>
>-doubles the read performance of a Samba drive. The best explanation I have seen for
>-this is that the Microsoft TCP/IP stack is slow in sending TCP ACKs.
>-</para>
>-
>-<para>
>-There have been reports that setting <parameter>socket options = SO_RCVBUF=8192</parameter> in smb.conf
>-can seriously degrade Samba performance on the loopback adaptor (IP Address 127.0.0.1). It is strongly
>-recommended that before specifying any settings for <parameter>socket options</parameter>, the effect
>-first be quantitatively measured on the server being configured.
>-</para>
>-
>-</sect1>
>-
>-<sect1>
>-<title>Read Size</title>
>-
>-<para>
>-The option <smbconfoption name="read size"/> affects the overlap of disk
>-reads/writes with network reads/writes. If the amount of data being
>-transferred in several of the SMB commands (currently SMBwrite, SMBwriteX, and
>-SMBreadbraw) is larger than this value, then the server begins writing
>-the data before it has received the whole packet from the network, or
>-in the case of SMBreadbraw, it begins writing to the network before
>-all the data has been read from disk.
>-</para>
>-
>-<para>
>-This overlapping works best when the speeds of disk and network access
>-are similar, having little effect when the speed of one is much
>-greater than the other.
>-</para>
>-
>-<para>
>-The default value is 16384, but little experimentation has been
>-done as yet to determine the optimal value, and it is likely that the best
>-value will vary greatly between systems anyway. A value over 65536 is
>-pointless and will cause you to allocate memory unnecessarily.
>-</para>
>-
>-</sect1>
>-
>-<sect1>
>-<title>Max Xmit</title>
>-
>-<para>
>-	At startup the client and server negotiate a <parameter>maximum transmit</parameter> size,
>-which limits the size of nearly all SMB commands. You can set the
>-maximum size that Samba will negotiate using the <smbconfoption name="max xmit"/> option
>-in &smb.conf;. Note that this is the maximum size of SMB requests that 
>-Samba will accept, but not the maximum size that the client will accept.
>-The client maximum receive size is sent to Samba by the client, and Samba
>-honors this limit.
>-</para>
>-
>-<para>
>-It defaults to 65536 bytes (the maximum), but it is possible that some
>-clients may perform better with a smaller transmit unit. Trying values
>-of less than 2048 is likely to cause severe problems.
>-In most cases the default is the best option.
>-</para>
>-
>-</sect1>
>-
>-<sect1>
>-<title>Log Level</title>
>-
>-<para>
>-If you set the log level (also known as <smbconfoption name="debug level"/>) higher than 2,
>-then you may suffer a large drop in performance. This is because the
>-server flushes the log file after each operation, which can be quite
>-expensive. 
>-</para>
>-</sect1>
>-
>-<sect1>
>-<title>Read Raw</title>
>-
>-<para>
>-The <smbconfoption name="read raw"/> operation is designed to be an optimized, low-latency
>-file read operation. A server may choose to not support it,
>-however, and Samba makes support for <smbconfoption name="read raw"/> optional, with it
>-being enabled by default.
>-</para>
>-
>-<para>
>-In some cases clients do not handle <smbconfoption name="read raw"/> very well and actually
>-get lower performance using it than they get using the conventional
>-read operations, so you might like to try <smbconfoption name="read raw">no</smbconfoption> and see what happens on your
>-network. It might lower, raise, or not affect your performance. Only
>-testing can really tell.
>-</para>
>-
>-</sect1>
>-
>-<sect1>
>-<title>Write Raw</title>
>-
>-<para>
>-The <smbconfoption name="write raw"/> operation is designed to be an optimized, low-latency
>-file write operation. A server may choose to not support it, however, and Samba makes support for
>-<smbconfoption name="write raw"/> optional, with it being enabled by default.
>-</para>
>-
>-<para>
>-Some machines may find <smbconfoption name="write raw"/> slower than normal write, in which
>-case you may wish to change this option.
>-</para>
>-
>-</sect1>
>-
>-<sect1>
>-<title>Slow Logins</title>
>-
>-<para>
>-Slow logins are almost always due to the password checking time. Using
>-the lowest practical <smbconfoption name="password level"/> will improve things. 
>-</para>
>-
>-</sect1>
>-
>-<sect1>
>-<title>Client Tuning</title>
>-
>-<para>
>-Often a speed problem can be traced to the client. The client (for
>-example Windows for Workgroups) can often be tuned for better TCP
>-performance. Check the sections on the various clients in 
>-<link linkend="Other-Clients">Samba and Other CIFS Clients</link>.
>-</para>
>-
>-</sect1>
>-
>-<sect1>
>-<title>Samba Performance Problem Due to Changing Linux Kernel</title>
>-
>-<para>
>-A user wrote the following to the mailing list:
>-</para>
>-
>-<blockquote>
>-<para>
>-<indexterm><primary>Gentoo</primary></indexterm>
>-<indexterm><primary>slow network</primary></indexterm>
>-I am running Gentoo on my server and Samba 2.2.8a. Recently I changed kernel versions from
>-<filename>linux-2.4.19-gentoo-r10</filename> to <filename>linux-2.4.20-wolk4.0s</filename>. Now I have a
>-performance issue with Samba.  Many of you will probably say,  <quote>Move to vanilla sources!</quote> Well, I
>-tried that and it didn't work. I have a 100MB LAN and two computers (Linux and Windows 2000). The Linux server
>-shares directories with DivX files, the client (Windows 2000) plays them via LAN. Before, when I was running
>-the 2.4.19 kernel, everything was fine, but now movies freeze and stop. I tried moving files between the
>-server and Windows, and it is terribly slow.
>-</para>
>-</blockquote>
>-
>-<para>
>-The answer he was given is:
>-</para>
>-
>-<blockquote>
>-<para>
>-<indexterm><primary>ifconfig</primary></indexterm>
>-<indexterm><primary>framing error</primary></indexterm>
>-<indexterm><primary>collisions</primary></indexterm>
>-Grab the mii-tool and check the duplex settings on the NIC.  My guess is that it is a link layer issue, not an
>-application layer problem. Also run ifconfig and verify that the framing error, collisions, and so on, look
>-normal for ethernet.
>-</para>
>-</blockquote>
>-
>-</sect1>
>-
>-<sect1>
>-<title>Corrupt tdb Files</title>
>-
>-<para>
>-<indexterm><primary>PDC</primary></indexterm>
>-<indexterm><primary>mbd kept spawning</primary></indexterm>
>-<indexterm><primary>/var/locks/*.tdb</primary></indexterm>
>-Our Samba PDC server has been hosting three TB of data to our 500+ users [Windows NT/XP]  for the last three
>-years using Samba without a problem.  Today all shares went very slow. Also, the main smbd kept spawning new
>-processes, so we had 1600+ running SMDB's (normally we average 250).  It crashed the SUN E3500 cluster twice.
>-After a lot of searching, I decided to <command>rm /var/locks/*.tdb</command>. Happy again.
>-</para>
>-
>-<para>
>-<emphasis>Question:</emphasis> Is there any method of keeping the *.tdb files in top condition, or
>-how can I detect early corruption?
>-</para>
>-
>-<para>
>-<indexterm><primary>tdbbackup</primary></indexterm>
>-<indexterm><primary>nmbd</primary></indexterm>
>-<emphasis>Answer:</emphasis> Yes, run <command>tdbbackup</command> each time after stopping nmbd and before starting nmbd.
>-</para>
>-
>-<para>
>-<emphasis>Question:</emphasis> What I also would like to mention is that the service latency seems
>-a lot lower than before the locks cleanup. Any ideas on keeping it top notch?
>-</para>
>-
>-<para>
>-<emphasis>Answer:</emphasis> Yes. Same answer as for previous question!
>-</para>
>-
>-</sect1>
>-
>-<sect1>
>-<title>Samba Performance is Very Slow</title>
>-
>-<para>
>-<indexterm><primary>slow performance</primary></indexterm>
>-A site reported experiencing very baffling symptoms with MYOB Premier opening and
>-accessing its data files. Some  operations on the file would take between 40 and
>-45 seconds.
>-</para>
>-
>-<para>
>-<indexterm><primary>printer monitor</primary></indexterm>
>-<indexterm><primary>pauses</primary></indexterm>
>-It turned out that the printer monitor program running on the Windows
>-clients was causing the problems. From the logs, we saw activity coming
>-through with pauses of about 1 second.
>-</para>
>-
>-<para>
>-<indexterm><primary>networks access</primary></indexterm>
>-<indexterm><primary>printing now</primary></indexterm>
>-Stopping the monitor software resulted in the networks access at normal
>-(quick) speed. Restarting the program caused the speed to slow down
>-again. The printer was a Canon LBP-810 and the relevant task was
>-something like CAPON (not sure on spelling). The monitor software
>-displayed a "printing now" dialog on the client during printing.
>-</para>
>-
>-<para>
>-We discovered this by starting with a clean install of Windows and
>-trying the application at every step of the installation of other software
>-process (we had to do this many times).
>-</para>
>-
>-<para>
>-Moral of the story: Check everything (other software included)!
>-</para>
>-
>-</sect1>
>-
>-</chapter>
>diff --git a/docs-xml/Samba3-HOWTO/index.xml b/docs-xml/Samba3-HOWTO/index.xml
>index b2af47a..e496ce4 100644
>--- a/docs-xml/Samba3-HOWTO/index.xml
>+++ b/docs-xml/Samba3-HOWTO/index.xml
>@@ -202,8 +202,6 @@ The chapters in this part each cover specific Samba features.
> 	<?latex \cleardoublepage ?>
> 	<xi:include href="TOSHARG-Compiling.xml"/>
> 	<?latex \cleardoublepage ?>
>-	<xi:include href="TOSHARG-Speed.xml"/>
>-	<?latex \cleardoublepage ?>
> 	<xi:include href="TOSHARG-SecureLDAP.xml"/>
> 	<?latex \cleardoublepage ?>
> 	<xi:include href="TOSHARG-Support.xml"/>
>-- 
>1.7.11.7
>
>
>From a8e9bed744a92d57ea4dbce0d6ffa6403493a5d4 Mon Sep 17 00:00:00 2001
>From: Andrew Bartlett <abartlet@samba.org>
>Date: Tue, 21 May 2013 20:50:30 +1000
>Subject: [PATCH 2/4] docs: Remove TOSHARG-HighAvailability which is made
> obsolete by CTDB
>
>This is mostly a lament on why this is hard, and while CTDB is still
>hard, this document tries to imply it is almost impossible, and makes
>no mention of the solution.
>
>Andrew Bartlett
>Reviewed-by: Jeremy Allison <jra@samba.org>
>(cherry picked from commit f632150e1b5a8d8a32753f43f7433b392f3a2136)
>---
> docs-xml/Samba3-HOWTO/TOSHARG-HighAvailability.xml | 500 ---------------------
> docs-xml/Samba3-HOWTO/index.xml                    |   2 -
> 2 files changed, 502 deletions(-)
> delete mode 100644 docs-xml/Samba3-HOWTO/TOSHARG-HighAvailability.xml
>
>diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-HighAvailability.xml b/docs-xml/Samba3-HOWTO/TOSHARG-HighAvailability.xml
>deleted file mode 100644
>index 1ce81d4..0000000
>--- a/docs-xml/Samba3-HOWTO/TOSHARG-HighAvailability.xml
>+++ /dev/null
>@@ -1,500 +0,0 @@
>-<?xml version="1.0" encoding="iso-8859-1"?>
>-<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
>-<chapter id="SambaHA">
>-<chapterinfo>
>-	&author.jht;
>-	&author.jeremy;
>-</chapterinfo>
>-
>-<title>High Availability</title>
>-
>-<sect1>
>-<title>Features and Benefits</title>
>-
>-<para>
>-<indexterm><primary>availability</primary></indexterm>
>-<indexterm><primary>intolerance</primary></indexterm>
>-<indexterm><primary>vital task</primary></indexterm>
>-Network administrators are often concerned about the availability of file and print
>-services. Network users are inclined toward intolerance of the services they depend
>-on to perform vital task responsibilities.
>-</para>
>-
>-<para>
>-A sign in a computer room served to remind staff of their responsibilities. It read:
>-</para>
>-
>-<blockquote>
>-<para>
>-<indexterm><primary>fail</primary></indexterm>
>-<indexterm><primary>managed by humans</primary></indexterm>
>-<indexterm><primary>economically wise</primary></indexterm>
>-<indexterm><primary>anticipate failure</primary></indexterm>
>-All humans fail, in both great and small ways we fail continually. Machines fail too.
>-Computers are machines that are managed by humans, the fallout from failure
>-can be spectacular. Your responsibility is to deal with failure, to anticipate it
>-and to eliminate it as far as is humanly and economically wise to achieve.
>-Are your actions part of the problem or part of the solution?
>-</para>
>-</blockquote>
>-
>-<para>
>-If we are to deal with failure in a planned and productive manner, then first we must
>-understand the problem. That is the purpose of this chapter.
>-</para>
>-
>-<para>
>-<indexterm><primary>high availability</primary></indexterm>
>-<indexterm><primary>CIFS/SMB</primary></indexterm>
>-<indexterm><primary>state of knowledge</primary></indexterm>
>-Parenthetically, in the following discussion there are seeds of information on how to
>-provision a network infrastructure against failure. Our purpose here is not to provide
>-a lengthy dissertation on the subject of high availability. Additionally, we have made
>-a conscious decision to not provide detailed working examples of high availability
>-solutions; instead we present an overview of the issues in the hope that someone will
>-rise to the challenge of providing a detailed document that is focused purely on
>-presentation of the current state of knowledge and practice in high availability as it
>-applies to the deployment of Samba and other CIFS/SMB technologies.
>-</para>
>-
>-</sect1>
>-
>-<sect1>
>-<title>Technical Discussion</title>
>-
>-<para>
>-<indexterm><primary>SambaXP conference</primary></indexterm>
>-<indexterm><primary>Germany</primary></indexterm>
>-<indexterm><primary>inspired structure</primary></indexterm>
>-The following summary was part of a presentation by Jeremy Allison at the SambaXP 2003
>-conference that was held at Goettingen, Germany, in April 2003. Material has been added
>-from other sources, but it was Jeremy who inspired the structure that follows.
>-</para>
>-
>-	<sect2>
>-	<title>The Ultimate Goal</title>
>-
>-	<para>
>-<indexterm><primary>clustering technologies</primary></indexterm>
>-<indexterm><primary>affordable power</primary></indexterm>
>-<indexterm><primary>unstoppable services</primary></indexterm>
>-	All clustering technologies aim to achieve one or more of the following:
>-	</para>
>-
>-	<itemizedlist>
>-		<listitem><para>Obtain the maximum affordable computational power.</para></listitem>
>-		<listitem><para>Obtain faster program execution.</para></listitem>
>-		<listitem><para>Deliver unstoppable services.</para></listitem>
>-		<listitem><para>Avert points of failure.</para></listitem>
>-		<listitem><para>Exact most effective utilization of resources.</para></listitem>
>-	</itemizedlist>
>-
>-	<para>
>-	A clustered file server ideally has the following properties:
>-<indexterm><primary>clustered file server</primary></indexterm>
>-<indexterm><primary>connect transparently</primary></indexterm>
>-<indexterm><primary>transparently reconnected</primary></indexterm>
>-<indexterm><primary>distributed file system</primary></indexterm>
>-	</para>
>-
>-	<itemizedlist>
>-		<listitem><para>All clients can connect transparently to any server.</para></listitem>
>-		<listitem><para>A server can fail and clients are transparently reconnected to another server.</para></listitem>
>-		<listitem><para>All servers serve out the same set of files.</para></listitem>
>-		<listitem><para>All file changes are immediately seen on all servers.</para>
>-			<itemizedlist><listitem><para>Requires a distributed file system.</para></listitem></itemizedlist></listitem>
>-		<listitem><para>Infinite ability to scale by adding more servers or disks.</para></listitem>
>-	</itemizedlist>
>-
>-	</sect2>
>-
>-	<sect2>
>-	<title>Why Is This So Hard?</title>
>-
>-	<para>
>-	In short, the problem is one of <emphasis>state</emphasis>.
>-	</para>
>-
>-	<itemizedlist>
>-		<listitem>
>-			<para>
>-<indexterm><primary>state information</primary></indexterm>
>-			All TCP/IP connections are dependent on state information.
>-			</para>
>-			<para>
>-<indexterm><primary>TCP failover</primary></indexterm>
>-			The TCP connection involves a packet sequence number. This
>-			sequence number would need to be dynamically updated on all
>-			machines in the cluster to effect seamless TCP failover.
>-			</para>
>-		</listitem>
>-		<listitem>
>-			<para>
>-<indexterm><primary>CIFS/SMB</primary></indexterm>
>-<indexterm><primary>TCP</primary></indexterm>
>-			CIFS/SMB (the Windows networking protocols) uses TCP connections.
>-			</para>
>-			<para>
>-			This means that from a basic design perspective, failover is not
>-			seriously considered.
>-			<itemizedlist>
>-				<listitem><para>
>-				All current SMB clusters are failover solutions
>-				&smbmdash; they rely on the clients to reconnect. They provide server
>-				failover, but clients can lose information due to a server failure.
>-<indexterm><primary>server failure</primary></indexterm>
>-				</para></listitem>
>-			</itemizedlist>
>-			</para>
>-		</listitem>
>-		<listitem>
>-			<para>
>-			Servers keep state information about client connections.
>-			<itemizedlist>
>-<indexterm><primary>state</primary></indexterm>
>-				<listitem><para>CIFS/SMB involves a lot of state.</para></listitem>
>-				<listitem><para>Every file open must be compared with other open files
>-						to check share modes.</para></listitem>
>-			</itemizedlist>
>-			</para>
>-		</listitem>
>-	</itemizedlist>
>-
>-		<sect3>
>-		<title>The Front-End Challenge</title>
>-
>-		<para>
>-<indexterm><primary>cluster servers</primary></indexterm>
>-<indexterm><primary>single server</primary></indexterm>
>-<indexterm><primary>TCP data streams</primary></indexterm>
>-<indexterm><primary>front-end virtual server</primary></indexterm>
>-<indexterm><primary>virtual server</primary></indexterm>
>-<indexterm><primary>de-multiplex</primary></indexterm>
>-<indexterm><primary>SMB</primary></indexterm>
>-		To make it possible for a cluster of file servers to appear as a single server that has one
>-		name and one IP address, the incoming TCP data streams from clients must be processed by the
>-		front-end virtual server. This server must de-multiplex the incoming packets at the SMB protocol
>-		layer level and then feed the SMB packet to different servers in the cluster.
>-		</para>
>-
>-		<para>
>-<indexterm><primary>IPC$ connections</primary></indexterm>
>-<indexterm><primary>RPC calls</primary></indexterm>
>-		One could split all IPC$ connections and RPC calls to one server to handle printing and user
>-		lookup requirements. RPC printing handles are shared between different IPC4 sessions &smbmdash; it is
>-		hard to split this across clustered servers!
>-		</para>
>-
>-		<para>
>-		Conceptually speaking, all other servers would then provide only file services. This is a simpler
>-		problem to concentrate on.
>-		</para>
>-
>-		</sect3>
>-
>-		<sect3>
>-		<title>Demultiplexing SMB Requests</title>
>-
>-		<para>
>-<indexterm><primary>SMB requests</primary></indexterm>
>-<indexterm><primary>SMB state information</primary></indexterm>
>-<indexterm><primary>front-end virtual server</primary></indexterm>
>-<indexterm><primary>complicated problem</primary></indexterm>
>-		De-multiplexing of SMB requests requires knowledge of SMB state information,
>-		all of which must be held by the front-end <emphasis>virtual</emphasis> server.
>-		This is a perplexing and complicated problem to solve.
>-		</para>
>-
>-		<para>
>-<indexterm><primary>vuid</primary></indexterm>
>-<indexterm><primary>tid</primary></indexterm>
>-<indexterm><primary>fid</primary></indexterm>
>-		Windows XP and later have changed semantics so state information (vuid, tid, fid)
>-		must match for a successful operation. This makes things simpler than before and is a
>-		positive step forward.
>-		</para>
>-
>-		<para>
>-<indexterm><primary>SMB requests</primary></indexterm>
>-<indexterm><primary>Terminal Server</primary></indexterm>
>-		SMB requests are sent by vuid to their associated server. No code exists today to
>-		effect this solution. This problem is conceptually similar to the problem of
>-		correctly handling requests from multiple requests from Windows 2000
>-		Terminal Server in Samba.
>-		</para>
>-
>-		<para>
>-<indexterm><primary>de-multiplexing</primary></indexterm>
>-		One possibility is to start by exposing the server pool to clients directly.
>-		This could eliminate the de-multiplexing step.
>-		</para>
>-
>-		</sect3>
>-
>-		<sect3>
>-		<title>The Distributed File System Challenge</title>
>-
>-		<para>
>-<indexterm><primary>Distributed File Systems</primary></indexterm>
>-		There exists many distributed file systems for UNIX and Linux.
>-		</para>
>-
>-		<para>
>-<indexterm><primary>backend</primary></indexterm>
>-<indexterm><primary>SMB semantics</primary></indexterm>
>-<indexterm><primary>share modes</primary></indexterm>
>-<indexterm><primary>locking</primary></indexterm>
>-<indexterm><primary>oplock</primary></indexterm>
>-<indexterm><primary>distributed file systems</primary></indexterm>
>-		Many could be adopted to backend our cluster, so long as awareness of SMB
>-		semantics is kept in mind (share modes, locking, and oplock issues in particular).
>-		Common free distributed file systems include:
>-<indexterm><primary>NFS</primary></indexterm>
>-<indexterm><primary>AFS</primary></indexterm>
>-<indexterm><primary>OpenGFS</primary></indexterm>
>-<indexterm><primary>Lustre</primary></indexterm>
>-		</para>
>-
>-		<itemizedlist>
>-			<listitem><para>NFS</para></listitem>
>-			<listitem><para>AFS</para></listitem>
>-			<listitem><para>OpenGFS</para></listitem>
>-			<listitem><para>Lustre</para></listitem>
>-		</itemizedlist>
>-
>-		<para>
>-<indexterm><primary>server pool</primary></indexterm>
>-		The server pool (cluster) can use any distributed file system backend if all SMB
>-		semantics are performed within this pool.
>-		</para>
>-
>-		</sect3>
>-
>-		<sect3>
>-		<title>Restrictive Constraints on Distributed File Systems</title>
>-
>-		<para>
>-<indexterm><primary>SMB services</primary></indexterm>
>-<indexterm><primary>oplock handling</primary></indexterm>
>-<indexterm><primary>server pool</primary></indexterm>
>-<indexterm><primary>backend file system pool</primary></indexterm>
>-		Where a clustered server provides purely SMB services, oplock handling
>-		may be done within the server pool without imposing a need for this to
>-		be passed to the backend file system pool.
>-		</para>
>-
>-		<para>
>-<indexterm><primary>NFS</primary></indexterm>
>-<indexterm><primary>interoperability</primary></indexterm>
>-		On the other hand, where the server pool also provides NFS or other file services,
>-		it will be essential that the implementation be oplock-aware so it can
>-		interoperate with SMB services. This is a significant challenge today. A failure
>-		to provide this interoperability will result in a significant loss of performance that will be
>-		sorely noted by users of Microsoft Windows clients.
>-		</para>
>-
>-		<para>
>-		Last, all state information must be shared across the server pool.
>-		</para>
>-
>-		</sect3>
>-
>-		<sect3>
>-		<title>Server Pool Communications</title>
>-
>-		<para>
>-<indexterm><primary>POSIX semantics</primary></indexterm>
>-<indexterm><primary>SMB</primary></indexterm>
>-<indexterm><primary>POSIX locks</primary></indexterm>
>-<indexterm><primary>SMB locks</primary></indexterm>
>-		Most backend file systems support POSIX file semantics. This makes it difficult
>-		to push SMB semantics back into the file system. POSIX locks have different properties
>-		and semantics from SMB locks.
>-		</para>
>-
>-		<para>
>-<indexterm><primary>smbd</primary></indexterm>
>-<indexterm><primary>tdb</primary></indexterm>
>-<indexterm><primary>Clustered smbds</primary></indexterm>
>-		All <command>smbd</command> processes in the server pool must of necessity communicate
>-		very quickly. For this, the current <parameter>tdb</parameter> file structure that Samba
>-		uses is not suitable for use across a network. Clustered <command>smbd</command>s must use something else.
>-		</para>
>-
>-		</sect3>
>-
>-		<sect3>
>-		<title>Server Pool Communications Demands</title>
>-
>-		<para>
>-		High-speed interserver communications in the server pool is a design prerequisite
>-		for a fully functional system. Possibilities for this include:
>-		</para>
>-
>-		<itemizedlist>
>-<indexterm><primary>Myrinet</primary></indexterm>
>-<indexterm><primary>scalable coherent interface</primary><see>SCI</see></indexterm>
>-			<listitem><para>
>-			Proprietary shared memory bus (example: Myrinet or SCI [scalable coherent interface]).
>-			These are high-cost items.
>-			</para></listitem>
>-		
>-			<listitem><para>
>-			Gigabit Ethernet (now quite affordable).
>-			</para></listitem>
>-		
>-			<listitem><para>
>-			Raw Ethernet framing (to bypass TCP and UDP overheads).
>-			</para></listitem>
>-		</itemizedlist>
>-
>-		<para>
>-		We have yet to identify metrics for  performance demands to enable this to happen
>-		effectively.
>-		</para>
>-
>-		</sect3>
>-
>-		<sect3>
>-		<title>Required Modifications to Samba</title>
>-
>-		<para>
>-		Samba needs to be significantly modified to work with a high-speed server interconnect
>-		system to permit transparent failover clustering.
>-		</para>
>-
>-		<para>
>-		Particular functions inside Samba that will be affected include:
>-		</para>
>-
>-		<itemizedlist>
>-			<listitem><para>
>-			The locking database, oplock notifications,
>-			and the share mode database.
>-			</para></listitem>
>-
>-			<listitem><para>
>-<indexterm><primary>failure semantics</primary></indexterm>
>-<indexterm><primary>oplock messages</primary></indexterm>
>-			Failure semantics need to be defined. Samba behaves the same way as Windows.
>-			When oplock messages fail, a file open request is allowed, but this is 
>-			potentially dangerous in a clustered environment. So how should interserver
>-			pool failure semantics function, and how should such functionality be implemented?
>-			</para></listitem>
>-
>-			<listitem><para>
>-			Should this be implemented using a point-to-point lock manager, or can this
>-			be done using multicast techniques?
>-			</para></listitem>
>-
>-		</itemizedlist>
>-
>-		</sect3>
>-	</sect2>
>-
>-	<sect2>
>-	<title>A Simple Solution</title>
>-
>-	<para>
>-<indexterm><primary>failover servers</primary></indexterm>
>-<indexterm><primary>exported file system</primary></indexterm>
>-<indexterm><primary>distributed locking protocol</primary></indexterm>
>-	Allowing failover servers to handle different functions within the exported file system
>-	removes the problem of requiring a distributed locking protocol.
>-	</para>
>-
>-	<para>
>-<indexterm><primary>high-speed server interconnect</primary></indexterm>
>-<indexterm><primary>complex file name space</primary></indexterm>
>-	If only one server is active in a pair, the need for high-speed server interconnect is avoided.
>-	This allows the use of existing high-availability solutions, instead of inventing a new one.
>-	This simpler solution comes at a price &smbmdash; the cost of which is the need to manage a more
>-	complex file name space. Since there is now not a single file system, administrators
>-	must remember where all services are located &smbmdash; a complexity not easily dealt with.
>-	</para>
>-
>-	<para>
>-<indexterm><primary>virtual server</primary></indexterm>
>-	The <emphasis>virtual server</emphasis> is still needed to redirect requests to backend
>-	servers. Backend file space integrity is the responsibility of the administrator.
>-	</para>
>-
>-	</sect2>
>-
>-	<sect2>
>-	<title>High-Availability Server Products</title>
>-
>-	<para>
>-<indexterm><primary>resource failover</primary></indexterm>
>-<indexterm><primary>high-availability services</primary></indexterm>
>-<indexterm><primary>dedicated heartbeat</primary></indexterm>
>-<indexterm><primary>LAN</primary></indexterm>
>-<indexterm><primary>failover process</primary></indexterm>
>-	Failover servers must communicate in order to handle resource failover. This is essential
>-	for high-availability services. The use of a dedicated heartbeat is a common technique to
>-	introduce some intelligence into the failover process. This is often done over a dedicated
>-	link (LAN or serial).
>-	</para>
>-
>-	<para>
>-<indexterm><primary>SCSI</primary></indexterm>
>-<indexterm><primary>Red Hat Cluster Manager</primary></indexterm>
>-<indexterm><primary>Microsoft Wolfpack</primary></indexterm>
>-<indexterm><primary>Fiber Channel</primary></indexterm>
>-<indexterm><primary>failover communication</primary></indexterm>
>-	Many failover solutions (like Red Hat Cluster Manager and Microsoft Wolfpack)
>-	can use a shared SCSI of Fiber Channel disk storage array for failover communication.
>-	Information regarding Red Hat high availability solutions for Samba may be obtained from
>-	<ulink url="http://www.redhat.com/docs/manuals/enterprise/RHEL-AS-2.1-Manual/cluster-manager/s1-service-samba.html">www.redhat.com</ulink>.
>-	</para>
>-
>-	<para>
>-<indexterm><primary>Linux High Availability project</primary></indexterm>
>-	The Linux High Availability project is a resource worthy of consultation if your desire is
>-	to build a highly available Samba file server solution. Please consult the home page at
>-	<ulink url="http://www.linux-ha.org/">www.linux-ha.org/</ulink>.
>-	</para>
>-
>-	<para>
>-<indexterm><primary>backend failures</primary></indexterm>
>-<indexterm><primary>continuity of service</primary></indexterm>
>-	Front-end server complexity remains a challenge for high availability because it must deal
>-	gracefully with backend failures, while at the same time providing continuity of service
>-	to all network clients.
>-	</para>
>-	
>-	</sect2>
>-
>-	<sect2>
>-	<title>MS-DFS: The Poor Man's Cluster</title>
>-
>-	<para>
>-<indexterm><primary>MS-DFS</primary></indexterm>
>-<indexterm><primary>DFS</primary><see>MS-DFS, Distributed File Systems</see></indexterm>
>-	MS-DFS links can be used to redirect clients to disparate backend servers. This pushes
>-	complexity back to the network client, something already included by Microsoft.
>-	MS-DFS creates the illusion of a simple, continuous file system name space that works even
>-	at the file level.
>-	</para>
>-
>-	<para>
>-	Above all, at the cost of complexity of management, a distributed system (pseudo-cluster) can
>-	be created using existing Samba functionality.
>-	</para>
>-
>-	</sect2>
>-
>-	<sect2>
>-	<title>Conclusions</title>
>-
>-	<itemizedlist>
>-		<listitem><para>Transparent SMB clustering is hard to do!</para></listitem>
>-		<listitem><para>Client failover is the best we can do today.</para></listitem>
>-		<listitem><para>Much more work is needed before a practical and manageable high-availability transparent cluster solution will be possible.</para></listitem>
>-		<listitem><para>MS-DFS can be used to create the illusion of a single transparent cluster.</para></listitem>
>-	</itemizedlist>
>-
>-	</sect2>
>-
>-</sect1>
>-</chapter>
>diff --git a/docs-xml/Samba3-HOWTO/index.xml b/docs-xml/Samba3-HOWTO/index.xml
>index e496ce4..66487f2 100644
>--- a/docs-xml/Samba3-HOWTO/index.xml
>+++ b/docs-xml/Samba3-HOWTO/index.xml
>@@ -161,8 +161,6 @@ The chapters in this part each cover specific Samba features.
> 	<?latex \cleardoublepage ?>
> 	<xi:include href="TOSHARG-Backup.xml"/>
> 	<?latex \cleardoublepage ?>
>-	<xi:include href="TOSHARG-HighAvailability.xml"/>
>-	<?latex \cleardoublepage ?>
> 	<xi:include href="TOSHARG-LargeFile.xml"/>
> 	<?latex \cleardoublepage ?>
> 	<xi:include href="TOSHARG-ConfigSmarts.xml"/>
>-- 
>1.7.11.7
>
>
>From f0c17abdf954faa0864b151f73f10cf3cbe9c5e5 Mon Sep 17 00:00:00 2001
>From: Andrew Bartlett <abartlet@samba.org>
>Date: Tue, 21 May 2013 20:44:26 +1000
>Subject: [PATCH 3/4] docs: Fix small errors in TOSHARG-Compiling
>
>Reviewed-by: Jeremy Allison <jra@samba.org>
>(cherry picked from commit e896f3c5bf5dee3c771985cd9dd2eb376481c22b)
>---
> docs-xml/Samba3-HOWTO/TOSHARG-Compiling.xml | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-Compiling.xml b/docs-xml/Samba3-HOWTO/TOSHARG-Compiling.xml
>index ac866a8..3a2b729 100644
>--- a/docs-xml/Samba3-HOWTO/TOSHARG-Compiling.xml
>+++ b/docs-xml/Samba3-HOWTO/TOSHARG-Compiling.xml
>@@ -119,7 +119,7 @@ gpg: BAD signature from <quote>Samba Distribution Verification Key</quote>
> 	<para>
> 	<indexterm><primary>configure</primary></indexterm>
> 	To build the binaries, run the program <userinput>./configure
>-	</userinput> in the top level director of the source tree. This should automatically 
>+	</userinput> in the top level directory of the source tree. This should automatically
> 	configure Samba for your operating system. If you have unusual 
> 	needs, then you may wish to first run:
> <screen>
>@@ -177,7 +177,7 @@ gpg: BAD signature from <quote>Samba Distribution Verification Key</quote>
> 
> 	<para>
> 	After you run configure, make sure that the 
>-	<filename>bin/include/config.h</filename> it generates contain lines like this:
>+	<filename>bin/default/include/config.h</filename> it generates contain lines like this:
> <programlisting>
> #define HAVE_KRB5 1
> #define HAVE_LDAP 1
>@@ -186,7 +186,7 @@ gpg: BAD signature from <quote>Samba Distribution Verification Key</quote>
> 
> 	<para>
> 	If it does not, configure did not find your KRB5 libraries or
>-	your LDAP libraries. Look in <filename>config.log</filename> to figure
>+	your LDAP libraries. Look in <filename>bin/config.log</filename> to figure
> 	out why and fix it.
> 	</para>
> 
>-- 
>1.7.11.7
>
>
>From 52ac08506db894e34d20eb3dccb8cd5bfe227d8a Mon Sep 17 00:00:00 2001
>From: Andrew Bartlett <abartlet@samba.org>
>Date: Sun, 26 May 2013 20:29:19 +1000
>Subject: [PATCH 4/4] docs: Remove all references to testprns
>
>Based on debian patch documentation2.patch by Christian Perrier <bubulle@debian.org>.
>
>This tool no longer exists in Samba.
>
>Andrew Bartlett
>
>Reviewed-by: Kai Blin <kai@samba.org>
>(cherry picked from commit 4ae3cdcd7151237a858f668357d08ab6916bdb3b)
>---
> docs-xml/manpages/nmbd.8.xml     |  1 -
> docs-xml/manpages/smb.conf.5.xml |  1 -
> docs-xml/manpages/smbd.8.xml     |  1 -
> docs-xml/using_samba/appd.xml    | 18 ------------------
> docs-xml/using_samba/ch01.xml    |  6 ------
> docs-xml/using_samba/ch07.xml    |  8 --------
> examples/tridge/smb.conf         |  8 --------
> 7 files changed, 43 deletions(-)
>
>diff --git a/docs-xml/manpages/nmbd.8.xml b/docs-xml/manpages/nmbd.8.xml
>index f666f58..0599ba3 100644
>--- a/docs-xml/manpages/nmbd.8.xml
>+++ b/docs-xml/manpages/nmbd.8.xml
>@@ -266,7 +266,6 @@
> 	<manvolnum>8</manvolnum></citerefentry>, <citerefentry><refentrytitle>smb.conf</refentrytitle>
> 	<manvolnum>5</manvolnum></citerefentry>, <citerefentry><refentrytitle>smbclient</refentrytitle>
> 	<manvolnum>1</manvolnum></citerefentry>, <citerefentry><refentrytitle>testparm</refentrytitle>
>-	<manvolnum>1</manvolnum></citerefentry>, <citerefentry><refentrytitle>testprns</refentrytitle>
> 	<manvolnum>1</manvolnum></citerefentry>, and the Internet 
> 	RFC's <filename>rfc1001.txt</filename>, <filename>rfc1002.txt</filename>. 
> 	In addition the CIFS (formerly SMB) specification is available 
>diff --git a/docs-xml/manpages/smb.conf.5.xml b/docs-xml/manpages/smb.conf.5.xml
>index 44411b0..dd4f858 100644
>--- a/docs-xml/manpages/smb.conf.5.xml
>+++ b/docs-xml/manpages/smb.conf.5.xml
>@@ -809,7 +809,6 @@ chmod 1770 /usr/local/samba/lib/usershares
> 	<manvolnum>8</manvolnum></citerefentry>, <citerefentry><refentrytitle>smbclient</refentrytitle>
> 	<manvolnum>1</manvolnum></citerefentry>, <citerefentry><refentrytitle>nmblookup</refentrytitle>
> 	<manvolnum>1</manvolnum></citerefentry>, <citerefentry><refentrytitle>testparm</refentrytitle>
>-	<manvolnum>1</manvolnum></citerefentry>, <citerefentry><refentrytitle>testprns</refentrytitle>
> 	<manvolnum>1</manvolnum></citerefentry>.</para>
> </refsect1>
> 
>diff --git a/docs-xml/manpages/smbd.8.xml b/docs-xml/manpages/smbd.8.xml
>index 98e76fb..0d246cd 100644
>--- a/docs-xml/manpages/smbd.8.xml
>+++ b/docs-xml/manpages/smbd.8.xml
>@@ -421,7 +421,6 @@
> 	<manvolnum>8</manvolnum></citerefentry>, <citerefentry><refentrytitle>smb.conf</refentrytitle>
> 	<manvolnum>5</manvolnum></citerefentry>, <citerefentry><refentrytitle>smbclient</refentrytitle>
> 	<manvolnum>1</manvolnum></citerefentry>, <citerefentry><refentrytitle>testparm</refentrytitle>
>-	<manvolnum>1</manvolnum></citerefentry>, <citerefentry><refentrytitle>testprns</refentrytitle>
> 	<manvolnum>1</manvolnum></citerefentry>, and the 
> 	Internet RFC's	<filename>rfc1001.txt</filename>, <filename>rfc1002.txt</filename>. 
> 	In addition the CIFS (formerly SMB) specification is available 
>diff --git a/docs-xml/using_samba/appd.xml b/docs-xml/using_samba/appd.xml
>index a3a23f8..018e590 100644
>--- a/docs-xml/using_samba/appd.xml
>+++ b/docs-xml/using_samba/appd.xml
>@@ -1315,24 +1315,6 @@ received 6 names
> 
> 
> 
>-<sect2 role="" label="D.1.11" id="appd-SECT-1.11">
>-<title>testprns</title>
>-
>-
>-<para>The<indexterm id="appd-idx-993761-0"><primary>testprns program</primary></indexterm>
>-<indexterm id="appd-idx-993761-1"><primary>printers</primary><secondary>names</secondary><tertiary>checking</tertiary></indexterm> <emphasis>testprns</emphasis> program checks a specified printer name against the system printer capabilities (<filename>printcap</filename>) file. Its command line is:</para>
>-
>-
>-<programlisting>testprns <replaceable>printername</replaceable> [<replaceable>printcapname</replaceable>]</programlisting>
>-
>-
>-<para>If the <literal>printcapname</literal> isn't specified, Samba attempts to use one located in the <filename>smb.conf</filename> file. If one isn't specified there, Samba will try <filename>/etc/printcap</filename>. If that fails, the program will generate an error.</para>
>-</sect2>
>-
>-
>-
>-
>-
> <sect2 role="" label="D.1.12" id="appd-SECT-1.12">
> <title>rpcclient</title>
> 
>diff --git a/docs-xml/using_samba/ch01.xml b/docs-xml/using_samba/ch01.xml
>index ca8bc13..01d7791 100644
>--- a/docs-xml/using_samba/ch01.xml
>+++ b/docs-xml/using_samba/ch01.xml
>@@ -1375,12 +1375,6 @@ SIMPLE           &lt;1E&gt;  GROUP       Registered
> </varlistentry>
> 
> 
>-<varlistentry><term>testprns</term>
>-<listitem><para>A program that tests whether various printers are recognized by the <filename>smbd</filename> daemon</para></listitem>
>-</varlistentry>
>-</variablelist>
>-
>-
> <para>Each significant release of Samba goes through a significant exposure test before it's announced. In addition, it is quickly updated afterward if problems or unwanted side-effects are found. The latest stable distribution as of this writing is Samba 2.0.5, the long-awaited production version of Samba 2.0. This book focuses on the functionality supported in Samba 2.0, as opposed to the older 1.9.<emphasis>x</emphasis> versions of Samba, which are now obsolete.</para>
> </sect1>
> 
>diff --git a/docs-xml/using_samba/ch07.xml b/docs-xml/using_samba/ch07.xml
>index 307cab7..988aab8 100644
>--- a/docs-xml/using_samba/ch07.xml
>+++ b/docs-xml/using_samba/ch07.xml
>@@ -306,14 +306,6 @@ lppause command:
> 	public: true</programlisting>
> 
> 
>-<para>Second, try the command <literal>testprns</literal> <replaceable>printername</replaceable>. This is a simple program that verifies that the specified printer is available in your <emphasis>printcap</emphasis> file. If your <emphasis>printcap</emphasis> file is not in the usual place, you can specify its full pathname as the second argument to the <emphasis>testprns</emphasis> command:</para>
>-
>-
>-<programlisting># testprns lp /etc/printcap
>-Looking for printer lp in printcap file /etc/printcap
>-Printer name lp is valid.</programlisting>
>-
>-
> <para>Next, log on as the guest user, go to the spooling directory, and ensure that you can print using the same command that <emphasis>testparm</emphasis> says Samba will use. As mentioned before, this will tell you if you need to change the guest account, as the default account may not be allowed to print.</para>
> 
> 
>diff --git a/examples/tridge/smb.conf b/examples/tridge/smb.conf
>index a2f269f..4aa40d8 100644
>--- a/examples/tridge/smb.conf
>+++ b/examples/tridge/smb.conf
>@@ -31,14 +31,6 @@
>    print ok = yes
>    print command = xmenu -heading "%s" OK&
> 
>-[testprn]
>-   comment = Test printer
>-   path = /tmp
>-   user = susan
>-   print ok = yes
>-   print command = cp %s /tmp/smb.%U.prn
>-   lpq command = cat /tmp/xxyz
>-
> [amd]
>    comment = amd area
>    path = /mount
>-- 
>1.7.11.7
>

Flags:

kai: review+

Actions: View

Attachments on bug 9906: 8923