diff options
| author | John Terpstra <jht@samba.org> | 2003-05-28 06:04:40 +0000 |
|---|---|---|
| committer | John Terpstra <jht@samba.org> | 2003-05-28 06:04:40 +0000 |
| commit | 6382556446dedcb87b92c3fda12a1b5c602f5b43 (patch) | |
| tree | dd234981fb6998856afc82914f25ff0867496b15 /docs/docbook/projdoc | |
| parent | 4f0b44ccebf2052f924a1fca6d68edf46baaef14 (diff) | |
| download | samba-6382556446dedcb87b92c3fda12a1b5c602f5b43.tar.gz samba-6382556446dedcb87b92c3fda12a1b5c602f5b43.tar.bz2 samba-6382556446dedcb87b92c3fda12a1b5c602f5b43.zip | |
Minor edits.
(This used to be commit 8ba64165ecd7266fb16ae127910eecdf6954f750)
Diffstat (limited to 'docs/docbook/projdoc')
| -rw-r--r-- | docs/docbook/projdoc/GROUP-MAPPING-HOWTO.xml | 2 | ||||
| -rw-r--r-- | docs/docbook/projdoc/Speed.xml | 22 |
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> |