!!! Overview
[{$pagename}] is the underlying [Data Store|DataStore] for [eDirectory]


[{$pagename}] is a [FLexible Adaptable Information Management] [database] engine for traditional as well as volatile and complex information. 

[{$pagename}] is a very scalable [database] engine that supports multiple readers and a single-writer concurrency model.

[{$pagename}] is an [Open Source] embeddable [database] engine developed by [Novell INC] and released under the [GPL] [license] in [2006|Year 2006]. 

By default eDirectory uses a [block] size of 4 KB. The [FLAIM Block Cache] size for caching the complete [DIB] is equal to the [DIB] size, and the size required for the [FLAIM Entry Cache] is about two to four times the [DIB] size.

!! [{$pagename}] Operation
[{$pagename}] organizes [data] in [blocks]. Some of the [blocks] are typically held in [memory]. They represent the [FLAIM Block Cache]. The [FLAIM Entry Cache] (sometimes called a record cache) [caches] logical entries from the [database]. [FLAIM Entry Cache] is constructed from the items in the [FLAIM Block Cache]. [{$pagename}] maintains [hash] tables for both [caches]. The [hash] bucket size is periodically adjusted based on the number of items.

* While retrieving an entry, [{$pagename}] first checks for the entry in the [FLAIM Entry Cache]. If the entry exists, the entry is returned. 
* If an entry is NOT in [FLAIM Entry Cache], then [FLAIM Block Cache] queried and if present, the entry is returned.
* If an entry is NOT in [FLAIM Block Cache] (and therefore not in [FLAIM Entry Cache]) then a disk read operation is necessary.

When an [Update] is preformed an an [eDirectory] entry, the corresponding [blocks] for that entry are not directly committed to the [File System], so the [File System] and [memory] might not be in sync. However, the updates made to the entry are logged to the [FLAIM Cache] and [Roll-Forward Log] ([RFL]). The [FLAIM checkpoint] process will periodically start a [CheckPointThread] will commit any [Dirty cache] items to [File System] and clean up the [Roll-Forward Log] if required.


[Least Recently Used] ([LRU]) is the replacement [algorithm] used for replacing items in the [FLAIM Cache].

!! [{$pagename}] Memory Subsystem
Server applications can perform significantly better when [RAM] is increased. Caching the [eDirectory] database in the [File System] __or__ in the [FLAIM Cache] can lead to improved performances of search and modify operations. 

However, you may not be able to [cache] the complete [DIB] in large deployments. Avoid using [Swap Space] even if it means reducing the [FLAIM Entry Cache] and [FLAIM Block Cache] sizes. 

Use the vmstat tool to find more information on the memory subsystem.

As [eDirectory] uses memory, each thread from the thread pool uses 1 MB of RAM for its stack. By default, the [FLAIM Cache] size is set to 200 MB.

Several [Loadable Module]s are started when [eDirectory] starts, but the [Loadable Module] architecture of [eDirectory] allows you to reduce the memory footprint of the process by not loading the unused modules (for example, [SecretStore], [LDAP], or [eMBox]). 

In addition, products like [DirXML] have some [Loadable Module] that run inside [eDirectory].

The [memory] used by [eDirectory] might appear to be growing. Although memory is freed by an [eDirectory] [Processes], the [memory] it might not be released to the [Operating System] free pool because the memory manager used internally by eDirectory tries to optimize the memory allocations for future. 
This is one of the reasons for __not recommending__ [FLAIM] dynamic configuration. 

Use the Top tool to find the approximate [Virtual Memory] size of the [NDSD] [Processes] in your deployment.

The maximum memory that can be allocated to a process is limited in several ways. A certain amount of [RAM] is used by the [Operating System] and other processes on the system. The [Operating System] can impose limitations on physical [RAM] that a process uses.

[Edirectory Indexes] are maintained with the [FLAIM Block Cache].

!! [{$pagename}] Settings
[_ndsdb.ini] file controls the settings for [{$pagename}]

!! [Roll-Forward Log]
[{$pagename}] logs operations for each update transaction in a [Roll-Forward Log] ([RFL]) file. An RFL is used to recover transactions from a system failure or when restoring from a backup. The RFL file is truncated
after every [CheckPointThread] is completed unless it is turned on (rflkeepfiles) by using a hot continuous backup (http://www.novell.com/documentation/edir88/edir88/data/a2n4mb7.html).

!! [{$pagename}] [ndstrace]
[ndstrace] with Flag [RECM] can be used to monitor [{$pagename}] operations

!! [FLAIM Attribute Containerization]
[{$pagename}] to ensure optimal utilization of the entry cache and enhanced performance of attribute [Search Responses] operations, FLAIM stores [attributes] with larger values or higher number of values in a separate location namely, Attribute Container. This process is referred to as [FLAIM Attribute Containerization]

!! [{$pagename}] History
[{$pagename}] was originally used in Groupwise product and [eDirectory], well [NetWare], used an embedded [RECMAN] [DataStore]. [RECMAN] was not capable of using [SubstringIndex] and other [LDAP Indexes] and the change to [{$pagename}] was done. This change also allowed for [Novell Directory Services] ([NDS]) to properly support [LDAP] and to be ported to other platforms such as [Windows Server], [Linux], and [UNIX].

!! Category
%%category [eDirectory]%%

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]

----
[#1] [http://en.wikipedia.org/wiki/Novell_eDirectory]