Add MDB description

doc/guide/admin/backends.sdf

@@ -139,7 +139,7 @@ configuration lines:
 >	include ./schema/core.schema
 >	
 >	database  ldif
->	directory "./ldif"
+>	directory ./ldif
 >	suffix    "dc=suretecsystems,dc=com"
 >	rootdn    "cn=LDIF,dc=suretecsystems,dc=com"
 >	rootpw    LDIF
@@ -187,6 +187,42 @@ H3: Further Information
 
 {{slapd-ldif}}(5)
 
+H2: MDB
+
+
+H3: Overview
+
+The {{mdb}} backend to {{slapd}}(8) is the upcoming primary backend for a
+normal {{slapd}} database.  It uses OpenLDAP's own Memory-Mapped Database ({{TERM:MDB}})
+library to store data and is intended to replace the Berkeley DB backends.
+
+It supports indexing like the BDB backends, but it uses no caching and requires
+no tuning to deliver maximum search performance.  Like {{hdb}}, it is also
+fully hierarchical and supports subtree renames in constant time.
+
+H3: back-mdb Configuration
+
+Unlike the BDB backends, the MDB backend can be instantiated with very few
+configuration lines:
+
+>	include ./schema/core.schema
+>
+>	database  mdb
+>	directory ./mdb
+>	suffix    "dc=suretecsystems,dc=com"
+>	rootdn    "cn=mdb,dc=suretecsystems,dc=com"
+>	rootpw    mdb
+>	maxsize   1073741824
+
+In addition to the usual parameters that a minimal configuration requires, the MDB
+backend requires a maximum size to be set. This should be the largest that
+the database is ever anticipated to grow (in bytes). The filesystem must also
+provide enough free space to accommodate this size.
+
+H3: Further Information
+
+{{slapd-mdb}}(5)
+
 H2: Metadirectory
 
 

doc/guide/admin/tuning.sdf

@@ -27,13 +27,20 @@ H3: Memory
 
 Scale your cache to use available memory and increase system memory if you can.
 
-See {{SECT:Caching}}
+See {{SECT:Caching}} for BDB cache tuning hints.
+Note that MDB uses no cache of its own and has no tuning options, so the Caching
+section can be ignored when using MDB.
 
 
 H3: Disks
 
-Use fast subsystems. Put each database and logs on separate disks configurable
-via {{DB_CONFIG}}:
+Use fast filesystems, and conduct your own testing to see which filesystem
+types perform best with your workload. (On our own Linux testing, EXT2 and JFS
+tend to provide better write performance than everything else, including
+newer filesystems like EXT4, BTRFS, etc.)
+
+Use fast subsystems. Put each database and logs on separate disks
+(for BDB this is configurable via {{DB_CONFIG}}):
 
 >       # Data Directory
 >       set_data_dir /data/db
@@ -315,9 +322,9 @@ it is generally recommended to be 3x"cachesize".
 {NOTE: The idlcachesize setting directly affects search performance}
 
 
-H3: {{slapd}}(8) Threads
+H2: {{slapd}}(8) Threads
 
-{{slapd}}(8) can process requests via a configurable number of thread, which 
+{{slapd}}(8) can process requests via a configurable number of threads, which 
 in turn affects the in/out rate of connections.
 
 This value should generally be a function of the number of "real" cores on 

doc/guide/preamble.sdf

@@ -224,6 +224,7 @@ LDAP Sync|LDAP Content Synchronization
 LDAPv3|LDAP, version 3
 LDIF|LDAP Data Interchange Format
 MD5|Message Digest 5
+MDB|Memory-Mapped Database
 MIB|Management Information Base
 MODDN|Modify DN
 MODRDN|Modify RDN