eDirectory data is loosely consistent, meaning that after a data modification and before synchronization, the data will be different from one replica to another. Several background processes are implemented to ensure synchronization of Directory data over time. The eDirectory background processes run periodically and are responsible for a number of operations that keep the database on all servers in the eDirectory tree synchronized. All of these background processes happen automatically in the background without user intervention; however, some processes allow limited intervention.
eDirectory background processes include
This process maintains tree connectivity. At certain times, each server in the eDirectory tree checks its tree name and modifies it if necessary. When each server in the tree comes up or eDirectory restarts, the Limber process initiates. Also, when a server receives a request to check the tree name from another server in the tree, or for any other reason needs to establish communications with another server in the tree, the Limber process initiates. A request to check the tree name can originate for two reasons.
When the Limber process is initiated, it checks the server's entry to make sure that it is in the right tree, that is, has the correct tree name and address. The Limber process can be initiated sooner than normal by executing a DSTRACE SET console command (SET DSTRACE = *L).
The algorithm for the Limber process proceeds as follows:
When the Limber process is initiated on a server, it first makes a list of server addresses to check that the server is in the right tree. This list includes servers holding replicas of the partition that holds the server object. If the procedure was prompted by a request to check the tree name, the operation inserts the server identified in the request at the head of the list.
The server then sends a Ping request to each server in the list, in order. The Limber process selects the responding server whose root-most entry is closest to the tree root. If two or more servers report the same distance from the root, the Limber process selects the one (if any) whose root-most partition replica is a master replica. Ties are broken by the order of servers in the list.\
If the current server holds the master replica of the root partition and the selected server does not, the process halts.
If the selected server has the same tree name as the current server, the process halts.
Authentication to the selected server is initiated through background authentication procedures. If authentication to that server succeeds, the Limber process assumes that server must be in the same Directory tree. The requesting server then changes its tree name to the one reported by the selected server.
A back link is stored as an object attribute to keep track of external references to the object. The Directory uses the Back Link attribute to keep track of servers holding external references of an entry. The Back Link attribute has two parts:
When creating an external reference, eDirectory also schedules the creation of a Back Link attribute for the entry. Periodically, the Back Link process checks the external reference to see if the original entry still exists and if there is a reason for the external reference to continue to exist (used in the connection table, file system, or referenced by a local entry). If the external reference is not needed, eDirectory removes it.
The Back Link process enables easy maintenance of the external references by periodically verifying the remote server name and remote ID of each Back Link attribute of entries. The Back Link process checks consistency automatically at intervals of 1500 minutes, or 25 hours. This default back link interval can be changed using a settable parameter in the SET DSTRACE console command (SET DSTRACE = !B [2-10,080 minutes]). Also, the Back Link process flag can be set in the SET DSTRACE console command (SET DSTRACE = *B), which forces the Back Link process to initiate sooner than the next regularly scheduled interval.
When an entry is deleted, back links make it possible for all references to the entry to be deleted. Back links also facilitate renaming and moving entries, because the corresponding changes can be made to the external references through the operation of the Back Link process. Thus, the Back Link process helps to maintain the integrity of external references by allowing them to be updated to reflect the changes made to the objects they refer to. The Back Link process resolves external references to make sure there is a real entry that it refers to, and for real entries the process makes sure that an external reference exists. A local bit in each external reference is used to keep track of the status of back links.
When a server creates an external reference to an entry, it sends a Create Back Link request to a server holding a writable copy of the entry. If the Create Back Link request fails, it retries periodically until the Back Link attribute is created.
When a server removes an external reference from its local database, it sends a Remove Back Link request to a server holding a writable entry for the entry. The server receiving the request checks the Entry Creation Time against the creation time of the actual entry to verify that the request is operating on the correct entry. This Remove Back Link request operation causes the back link to be deleted.
The Janitor process performs two tasks:
The Janitor scans the partition and checks the Replica Up To attribute to determine which values and entries can be purged. A value can be purged from an entry if:
The Janitor purges the value if both conditions are met. As part of purging the value, the Janitor performs special processing for counter syntax values to compute the total counter values.
Once the Janitor has inspected all values for an entry, it determines whether the entire entry can be purged. It purges any entry that:
While scanning the partition, the Janitor builds two lists:
The Janitor also checks if the partition's root entry has been renamed; if so, the Janitor notifies all external references of the root entry of the new name. In addition, the Janitor purges Move expectations that are more than ten minutes old.
The Janitor then uses the two lists it generated in scanning the partitions to synchronize the external references.
For each entry in the Release ID List, the Janitor sends a Release Moved Entry request to the destination entry. If this request is successful, the obituary can then be purged.
For each entry in the Notify External Reference list, the Janitor requests external reference synchronization and specifies the operation that must be performed on the external reference.
This process has the following functions: