summaryrefslogtreecommitdiff
path: root/docs/Samba3-HOWTO/TOSHARG-LargeFile.xml
diff options
context:
space:
mode:
authorJohn Terpstra <jht@samba.org>2005-06-16 02:10:11 +0000
committerGerald W. Carter <jerry@samba.org>2008-04-23 08:46:49 -0500
commit66561b0fdadbff6f2b6bb496064d558d6fa0770e (patch)
treea6b03abd362179db7e741d497bcdc12a8f096fa5 /docs/Samba3-HOWTO/TOSHARG-LargeFile.xml
parentfa96398866a4bcdcc13b42ab4f8d3f516cd9238a (diff)
downloadsamba-66561b0fdadbff6f2b6bb496064d558d6fa0770e.tar.gz
samba-66561b0fdadbff6f2b6bb496064d558d6fa0770e.tar.bz2
samba-66561b0fdadbff6f2b6bb496064d558d6fa0770e.zip
PHPTR Edit 2. More to come.
(This used to be commit bc4d2f60cefa126415b06440280761d19e8c0d21)
Diffstat (limited to 'docs/Samba3-HOWTO/TOSHARG-LargeFile.xml')
-rw-r--r--docs/Samba3-HOWTO/TOSHARG-LargeFile.xml34
1 files changed, 17 insertions, 17 deletions
diff --git a/docs/Samba3-HOWTO/TOSHARG-LargeFile.xml b/docs/Samba3-HOWTO/TOSHARG-LargeFile.xml
index 44f054236e..d227638cbd 100644
--- a/docs/Samba3-HOWTO/TOSHARG-LargeFile.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-LargeFile.xml
@@ -9,25 +9,25 @@
<title>Handling Large Directories</title>
<para>
-Samba-3.0.12 implements a solution for sites that have experienced performance degradation do to the
+Samba-3.0.12 implements a solution for sites that have experienced performance degradation due to the
problem of using Samba-3 with applications that need large numbers of files (100,000 or more) per directory.
</para>
<para>
The key was fixing the directory handling to read only the current list requested instead of the old
-(up to samba-3.0.11) behaviour of reading the entire directory into memory before doling out names.
-Normally this would have broken OS/2 applications which have very strange delete semantics, but by
-stealing logic from Samba4 (thanks tridge) the current code in 3.0.12 handles this correctly.
+(up to samba-3.0.11) behavior of reading the entire directory into memory before doling out names.
+Normally this would have broken OS/2 applications, which have very strange delete semantics, but by
+stealing logic from Samba4 (thanks, Tridge), the current code in 3.0.12 handles this correctly.
</para>
<para>
-To set up an application that needs large number of files per directory in a way that does not
-damage performance unduly follow these steps:
+To set up an application that needs large numbers of files per directory in a way that does not
+damage performance unduly, follow these steps:
</para>
<para>
-Firstly, you need to canonicalize all the files in the directory to have one case, upper or lower - take your
-pick (I chose upper as all my files were already upper case names). Then set up a new custom share for the
+First, you need to canonicalize all the files in the directory to have one case, upper or lower &smbmdash; take your
+pick (I chose upper because all my files were already uppercase names). Then set up a new custom share for the
application as follows:
<screen>
[bigshare]
@@ -42,29 +42,29 @@ application as follows:
<para>
Of course, use your own path and settings, but set the case options to match the case of all the files in your
-directory. The path should point at the large directory needed for the application - any new files created in
-there and in any paths under it will be forced by smbd into upper case - but smbd will no longer have to scan
-the directory for names - it knows that if a file does not exist in upper case then it doesn't exist at all.
+directory. The path should point at the large directory needed for the application &smbmdash; any new files created in
+there and in any paths under it will be forced by smbd into uppercase, but smbd will no longer have to scan
+the directory for names: it knows that if a file does not exist in uppercase, then it doesn't exist at all.
</para>
<para>
The secret to this is really in the <smbconfoption name="case sensitive">True</smbconfoption>
line. This tells smbd never to scan for case-insensitive versions of names. So if an application asks for a file
-called <filename>FOO</filename>, and it can not be found by a simple stat call, then smbd will return file not
+called <filename>FOO</filename>, and it cannot be found by a simple stat call, then smbd will return file not
found immediately without scanning the containing directory for a version of a different case. The other
<filename>xxx case xxx</filename> lines make this work by forcing a consistent case on all files created by smbd.
</para>
<para>
-Remember, all files and directories under the <parameter>path</parameter> directory must be in upper case
-with this &smb.conf; stanza as smbd will not be able to find lower case filenames with these settings. Also
-note this is done on a per-share basis, allowing this to be set only for a share servicing an application with
-this problematic behaviour (using large numbers of entries in a directory) - the rest of your smbd shares
+Remember, all files and directories under the <parameter>path</parameter> directory must be in uppercase
+with this &smb.conf; stanza because smbd will not be able to find lowercase filenames with these settings. Also
+note that this is done on a per-share basis, allowing this parameter to be set only for a share servicing an application with
+this problematic behavior (using large numbers of entries in a directory) &smbmdash; the rest of your smbd shares
don't need to be affected.
</para>
<para>
-This makes smbd much faster when dealing with large directories. My test case has over 100,000 files and
+This makes smbd much faster when dealing with large directories. My test case has over 100,000 files, and
smbd now deals with this very efficiently.
</para>