The following are LSM terms and definitions.
A plex whose subdisks are associated at specific offsets within the address range of the plex, and extend in the plex address range for the length of the subdisk. This layout allows regions of one or more disks to create a plex, rather then a single big region.
A set of files that are saved using the
volsave(8)
command and
can be used to restore an LSM configuration.
By default, an LSM description
set is saved in a timestamped directory under the
/usr/var/lsm/db
directory.
Disks exist as two entities:
A physical disk on which all data is ultimately stored and which exhibits all the behaviors of the underlying technology.
An LSM representation of disks which, while mapping one-to-one with the physical disks, are just presentations of units from which allocations of storage are made
The difference is that a physical disk presents the image of a device with a definable geometry with a definable number of cylinders, heads, and so on while the LSM disk is simply a unit of allocation with a name and a size.
A configuration record that defines the path to a disk. Disk access records most often name a unit number. LSM uses the disk access records stored in a system to find all disks attached to the system. Disk access records do not identify particular physical disks.
Through the use of disk IDs, LSM allows you to move disks between controllers, or to different locations on a controller. When you move a disk, a different disk access record is used to access the disk, although the disk media record continues to track the actual physical disk.
On some systems, LSM builds a list of disk access records automatically,
based on the list of all devices attached to the system.
On these systems,
it is not necessary to define disk access records explicitly.
On other systems,
you must define disk access records with the
/sbin/voldisk define
command.
Specialty disks, such as RAM disks or floppy disks, are
likely to require explicit
/sbin/voldisk define
commands.
Disk access records are identified by their disk access names (also known as DA names).
A group of disks that share a common configuration. A configuration consists of a set of records describing objects including disks, volumes, plexes, and subdisks that are associated with one particular disk group. Each disk group has an administrator-assigned name that you use to to reference that disk group. Each disk group has an internally defined unique disk group ID, which is used to differentiate two disk groups with the same administrator-assigned name.
Disk groups provide a method to partition the configuration database, so that the database size is not too large and so that database modifications do not affect too many drives. They also allow LSM to operate with groups of physical disk media that can be moved between systems.
Disks and disk groups have a circular relationship: disk groups are formed from disks, and disk group configurations are stored on disks. All disks in a disk group are stamped with a disk group ID, which is a unique identifier for naming disk groups. Some or all disks in a disk group also store copies of the configuration of the disk group.
A disk group configuration is a small database that contains all volume, plex, subdisk, and disk media records. These configurations are replicated onto some or all disks in the disk group, often with two copies on each disk. Because these databases are stored on disk groups, record associations cannot span disk groups. Thus, you cannot define a subdisk on a disk in one disk group and associate it with a volume in another disk group.
A 64 byte universally unique identifier that is assigned to
a disk group when the disk group is created with
/sbin/voldg init
command.
This identifier is in addition to the disk group name,
which you assigned.
The disk group ID is used to check for disk groups that
have the same administrator-assigned name but are actually different.
Disk group records define several different types of names for a disk group. The different types of names are as follows:
The real name is the name of the disk group, as the name is defined on disk. This name is stored in the disk group configuration, and is also stored in the disk headers of all disks in the disk group.
The
alias name
is the standard name that
the system uses when referencing the disk group.
References to the disk group
name usually mean the alias name.
Volume and plex device directories are
structured into subdirectories based on the disk group alias name.
Typically,
the disk group's alias name and real name are identical.
A local alias is
useful for gaining access to a disk group with a name that conflicts with
other disk groups in the system, or that conflicts with records in the
rootdg
disk group.
The disk group ID is a 64-byte identifier that represents the unique ID of the disk group. All disk groups on all systems should have a different disk group ID, even if they have the same real name. This identifier is stored in the disk headers of all disks in the disk group. It is used to ensure that the LSM software does not confuse two disk groups which were created with the same name.
A block stored in a private region of a disk and that defines several properties of the disk. The disk header defines the:
Size of the private region
Location and size of the public region
Unique disk ID for the disk
Disk group ID and disk group name (if the disk is currently associated with a disk group)
Host ID for a host that has exclusive use of the disk
A 64 byte universally unique identifier that is assigned to
a physical disk when its private region is initialized with the
/sbin/voldisk init
command.
The disk ID is stored in the disk media
record so that the physical disk can be related to the disk media record at
system startup.
A reference to a physical disk, or possibly a disk partition. This record can be thought of as a physical disk identifier for the disk or partition. Disk media records are configuration records that provide a name (known as the disk media name or DM name) that you use to reference a particular disk independent of its location on the system's various disk controllers. Disk media records reference particular physical disks through a disk ID, which is a unique identifier that is assigned to a disk when it is initialized for use with the LSM software.
Operations are provided to set or remove the disk ID stored in a disk media record. Such operations have the effect of removing or replacing disks, with any associated subdisks being removed or replaced along with the disk.
A name, usually assigned by you, that identifies a particular
host.
Host IDs are used to assign ownership to particular physical disks.
When a disk is part of a disk group that is in active use by a particular
host, the disk is stamped with that host's host ID.
If another system attempts
to access the disk, it detects that the disk has a non-matching host ID and
disallows access until the first system discontinues use of the disk.
Use
the
/sbin/voldisk clearimport
command to clear the host
ID stored on a disk for system failures that do not clear the host ID,
If a disk is a member of a disk group and has a host ID that matches a particular host, then that host will import the disk group as part of system startup.
A log kept in the private region on the disk and that is written
by LSM kernel.
The log contains records describing the state of volumes in
the disk group.
This log provides a mechanism for the kernel to persistently
register state changes so that the
vold
daemon is guaranteed
to detect the state changes even in the event of a system failure.
A copy of a volume's logical data address space, also sometimes known as a mirror. A volume can have up to eight plexes associated with it. Each plex is, at least conceptually, a copy of the volume that is maintained consistently in the presence of volume I/O and reconfigurations. Plexes represent the primary means of configuring storage for a volume. Plexes can have a striped or concatenated organization (layout).
If the plexes of a volume contain different data, then the plexes are said to be inconsistent. This is only a problem if LSM is unaware of the inconsistencies, as the volume can return differing results for consecutive reads.
Plex inconsistency is a serious compromise of data integrity. This inconsistency is caused by write operations that start around the time of a system failure, if parts of the write complete on one plex, but not the other. If the plexes are not first synchronized to contain the same data, plexes are inconsistent after creation of a mirrored volume. An important part of LSM is to ensure that consistent data is returned to any application that reads a volume. This may require that plex consistency of a volume be `recovered' by copying data between plexes so that they have the same contents. Alternatively, you can put a volume into a state such that reads from one plex are automatically written back to the other plexes, making the data consistent for that volume offset.
Disks used by LSM contain two special regions: a private region and a public region. Usually, each region is formed from a complete partition of the disk; however, the private and public regions can be allocated from the same partition.
The private region of a disk contains various on-disk structures that are used by LSM for various internal purposes. Each private region begins with a disk header that identifies the disk and its disk group. Private regions can also contain copies of a disk group's configuration, and copies of the disk group's kernel log.
The public region of a disk is the space reserved for allocating subdisks. Subdisks are defined with offsets that are relative to the beginning of the public region of a particular disk. Only one contiguous region of disk can form the public region for a particular disk.
A configurable policy for switching between plexes for volume reads. When a volume has more than one enabled associated plex, LSM distributes reads between the plexes to distribute the I/O load and thus increase total possible bandwidth of reads through the volume. You set the read policy. Read policy choices include:
round-robin
For every other read operation, switch to a different plex from the previous read operation. Given three plexes, this will switch between each of the three plexes, in order.
preferred plex
This read policy specifies a particular plex that is used to satisfy read requests. In the event that a read request cannot be satisfied by the preferred plex, this policy changes to round-robin.
select
This read policy is the default policy, and adjusts to use an appropriate read policy based on the set of plexes associated with the volume. If exactly one enabled read-write striped plex is associated with the volume, then that plex is chosen automatically as the preferred plex; otherwise, the round-robin policy is used. If a volume has one striped plex and one non-striped plex, preferring the striped plex often yields better throughput.
Each system requires one special disk group, called
rootdg.
This group is generally the default for most utilities.
In addition to defining the regular disk group information, the configuration
for the root disk group contains local information that is specific to a disk
group and that is not intended to be movable between systems.
A plex that places data evenly across each of its associated subdisks. A plex has a characteristic number of stripe columns (represented by the number of associated subdisks) and a characteristic stripe width. The stripe width defines how much data with a particular address is allocated to one of the associated subdisks. Given a stripe width of 128 blocks, and two stripe columns, the first group of 128 blocks is allocated to the first subdisk, the second group of 128 blocks is allocated to the second subdisk, the third group to the first subdisk, and so on.
A region of storage allocated on a disk for use by a volume. Subdisks are associated to volumes through plexes. You organize one or more subdisks to form plexes based on a plex layout: striped or concatenated. Subdisks are defined relative to disk media records.
volboot
fileThe
volboot
file is a special file (usually
stored in
/etc/vol/volboot) that is used to bootstrap the
root disk group and to define a system's host ID.
In addition to a host ID,
the
volboot
file contains a list of disk access records.
On system startup, this list of disks is scanned to find a disk that is a
member of the
rootdg
disk group and that is stamped with
this system's host ID.
When such a disk is found, its configuration is read
and is used to get a more complete list of disk access records that are used
as a second-stage bootstrap of the root disk group, and to locate all other
disk groups.
A virtual disk device that looks to applications and file systems like a regular disk partition device. Volumes present block and raw device interfaces that are compatible in their use. A volume can be mirrored, spanned across disk drives, moved to use different storage, and striped. You can change the configuration of a volume without causing disruption to applications or file systems that are using the volume.
Volume records define the characteristics of particular volume
devices.
The name of a volume record defines the node name used for files
in the
/dev/vol
and
/dev/rvol
directories.
The block device for a particular volume, which can be used as an argument
to the
mount
command has the path
/dev/vol/groupname/volume.
See the
mount(8)
reference page for more information on the
mount
command.