| Technical |
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.
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.
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
The component belonging the the volumes, above, will be called: Stripe1-01, Stripe1-02, Raid1-01, Raid1-02, Volume1-01, Volume1-02, etc
When objects are deleted, new ones will take the lowest value of name available.
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.