summaryrefslogtreecommitdiff
path: root/docs/docbook
diff options
context:
space:
mode:
Diffstat (limited to 'docs/docbook')
-rw-r--r--docs/docbook/projdoc/GROUP-MAPPING-HOWTO.xml2
-rw-r--r--docs/docbook/projdoc/Speed.xml22
2 files changed, 16 insertions, 8 deletions
diff --git a/docs/docbook/projdoc/GROUP-MAPPING-HOWTO.xml b/docs/docbook/projdoc/GROUP-MAPPING-HOWTO.xml
index d00d241b53..8104fcd647 100644
--- a/docs/docbook/projdoc/GROUP-MAPPING-HOWTO.xml
+++ b/docs/docbook/projdoc/GROUP-MAPPING-HOWTO.xml
@@ -302,7 +302,7 @@ manually before putting them into active service.
<title>Adding MS Windows Groups to MS Windows Groups Fails</title>
<para>
- Samba-3 does NOT support nexted groups from the MS Windows control environment.
+ Samba-3 does NOT support nested groups from the MS Windows control environment.
</para>
</sect2>
diff --git a/docs/docbook/projdoc/Speed.xml b/docs/docbook/projdoc/Speed.xml
index 448ce61663..e2a522a1ac 100644
--- a/docs/docbook/projdoc/Speed.xml
+++ b/docs/docbook/projdoc/Speed.xml
@@ -248,23 +248,31 @@ error, collisions, etc... look normal for ethernet.
<title>Corrupt tdb Files</title>
<para>
-<screen>
-Well today it happend.... our first major troubles using samba. This is
-no complaints but just some questions :-)
+Well today it happend, our first major problem using samba.
Our samba PDC server has been hosting 3 TB of data to our 500+ users
[Windows NT/XP] for the last 3 years using samba, no problem.
But today all shares went SLOW; very slow. Also the main smbd kept
-spawning new processes so we had 1600+ running smbd's.... ( while
-normally we avg. 250 ).
+spawning new processes so we had 1600+ running smbd's (normally we avg. 250).
It crashed the SUN E3500 cluster twice. After alot of searching I
-decided to rm ./var/locks/*.tbl and YES I was happy again.
+decided to <command>rm /var/locks/*.tbl</command>. Happy again.
+</para>
+<para>
Q1) Is there any method of keeping the *.tbl files in top condition or
how to early detect corruption?
+</para>
+
+<para>
+A1) Yes, run <command>tdbbackup</command> each time after stoping nmbd and before starting nmbd.
+</para>
+<para>
Q2) What I also would like to mention is that the service latency seems
alot lower then before the locks cleanup, any ideas on keeping it top notch?
-</screen>
+</para>
+
+<para>
+A2) Yes! Samba answer as for Q1!
</para>
</sect1>