Database - Overview

Layout of Disk

Just after the dummy partition table, there is the first LDM structure.
The Private Header (PRIVHEAD) is a table of accounting information. It
contains a version number, a unique GUID for the disk and the location of
each of the other LDM structures. If this structure is missing or damaged,
then there are two backup copies.

The LDM structures don't seem to vary in size, but the Private Header is the
definitive reference. The LDM database takes up the last 1MiB of the
physical disk, which is why you need a small amount of space to upgrade to a
dynamic disk. If the disk is reverted to being a basic disk, then all
traces of the LDM database is removed.

Layout of LDM

The PRIVHEAD gives the location and size of the database. The first
structure in the LDM is a Table of Contents (TOCBLOCK). This lists which
high-level we can expect. At the moment there are only two: the
config section which contains the actual database of partitions and
volumes; the log section contains a journal of changes to the
database. There are four copies of the TOCBLOCK, but they seem to be
identical at all times.

The config section contains a VMDB and many VBLKs. Each VBLK represents a
disk group, disk, partition, component (container) or volume.

The Journal (KLOG) is just an index of changes to the database. The actual
pending changes are kept in the main database.

VBLK Naming

Internally, each disk, partition, component and volume is given a unique
name. Disk groups are named after the machine, e.g. HomeDg0. Disks are
named Disk1, Disk2, etc. The partitions for Disk1 are then called Disk1-01,
Disk1-02, etc.

Striped volumes will be called Stripe1, Stripe2, etc
RAID volumes will be called Raid1, Raid2, etc
Simple, spanned and mirrored volumes will be called Volume1, Volume2, etc

When objects are deleted, new ones will take the lowest value of name
available.

Example Volumes

Below are some example volumes. The diagrams show which VBLKs will be
present and how they are related.

Key:

Simple Volume The easiest example is the Simple Volume. The
filesystem takes up exactly one partition on one disk.

If another partition is added to this volume type, then volume will be
promoted to a Spanned Volume (below).

Mirrored Volume This is easily identified. The same volume information is
sent to two components, partitions and disks. The components don't alter
the data at all.

With two more partitions, it is possible to extend the volume. The two
components will have two children each, i.e. a Mirrored Spanned Volume (see
below).

Another partition could be added to this volume type, creating a third
mirror section, giving the Volume a third child.

Striped, RAID5, Spanned Volume This is the most interesting layout.
The component controls how the volume information is transformed before
being sent to two or more partitions.

With a Spanned Volume the partitions are joined together in a linear manner.
The beginning of the filesystem is written to the first partition and the
next part to the second partition, etc.

For a striped volume, the filesystem is divided into chunks, usually 64kB.
The first chunk is written to partition 1, the second to partition 2, for
each partition, then it wraps around.

A RAID5 volume usually has a chunk size of 16kB. This type requires a
minimun of three partitions. For each set of chunks there is an additional
chunk which contains parity information, which gives the volume fault
tolerance.

If another partition is added to any of these volumes, then the filesystem
can be extended into it. This will give the component more children.

Mirrored Stripe, Mirrored Spanned Volume This shows how different
ideas can be combined. The volume information is written identically to two
components which can either Stripe or Span the filesystem.

These volumes can be extended, in two ways. Adding another mirror would
require two more partitions. Extending the volume, would require four more
partitions.