vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
NAME [Toc] [Back]
vxintro - introduction to the VERITAS Volume Manager utilities
SYNOPSIS [Toc] [Back]
vxassist, vxclustadm, vxconfigd, vxdco, vxdctl, vxdg, vxdisk,
vxdiskadd, vxdiskadm, vxedit, vxevac, vxinfo, vxinstall, vxiod, vxmake,
vxmend, vxmirror, vxnotify, vxpfto, vxplex, vxprint, vxr5check,
vxreattch, vxrecover, vxrelayout, vxrelocd, vxresize, vxrlink, vxrvg,
vxsd, vxsparecheck, vxstat, vxtask, vxtrace, vxvmconvert, vxvol
DESCRIPTION [Toc] [Back]
The VERITAS Volume Manager (VxVM) utilities provide a shell-level
interface for use by system administrators and high-level applications
and scripts to query and manipulate objects managed through VxVM.
GLOSSARY [Toc] [Back]
concatenated plex
A plex whose subdisks are associated at specific offsets
within the address range of the plex, and extend into the
plex address range for the length of the subdisk. This
layout allows regions of one or more disks to create a plex,
rather than a single big region.
data change map
The data change map (DCM) is a bit-map which represents
regions in the volume. When a write to a region occurs, the
corresponding bit in the DCM is turned on. It is used by
VVR for both log overflow protection and automatic secondary
synchronization.
data volume
A volume being used as a child of an RVG. For a primary RVG,
a data volume contains the primary copy of that volume data.
For a secondary RVG, a data volume contains a copy of the
corresponding remote primary data volume data. Secondary
data volumes are only writable with updates from the
primary. The secondary RVG must contain a data volume
corresponding to each primary data volume.
disk Disks exist as two entities. One is the physical disk on
which all data is ultimately stored and which exhibits all
the behaviors of the underlying technology. The other is
the VERITAS Volume Manager presentation of disks which,
while mapping one-to-one with the physical disks, are just
presentations of units from which allocations of storage are
made. As an example, a physical disk presents the image of
a device with a definable geometry with a definable number
of cylinders, heads, and so forth, whereas a VERITAS Volume
Manager disk (VM disk) is simply a unit of allocation with a
name and a size.
- 1 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
disk access record
A configuration record that defines a pathway to a disk.
The disk access records most commonly name a particular
controller number, target ID, and logical unit number. The
list of all disk access records stored in a system is used
to find all disks attached to the system. Disk access
records do not identify particular physical disks.
Disk access records are identified by their disk access
names (also known as DA names).
Through the use of disk IDs, VxVM allows disks to be moved
between controllers, or to different locations on a
controller. When a disk is moved, a different disk access
record is used when accessing the disk, although the disk
media record continues to track the actual physical disk.
On some systems, VxVM 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, disk
access records must be defined explicitly with the vxdisk
define operation. Specialty disks (such as RAM disks or
floppy disks) are likely to require explicit vxdisk define
operations on all systems.
disk group
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 can be
used by the administrator 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 VxVM 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 database of the disk
group.
- 2 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
disk group configuration
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, usually with one copy on each disk. Because
these databases are stored within disk groups, record
associations cannot span disk groups. Thus, a subdisk
defined on a disk in one disk group cannot be associated
with a volume in another disk group.
disk header
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, the location and
size of the public region, the unique disk ID for the disk,
the disk group ID and disk group name (if the disk is
currently associated with a disk group), and the host ID for
a host that has exclusive use of the disk.
disk ID A 64-byte universally unique identifier that is assigned to
a physical disk when its private region is initialized with
the vxdisk init operation. 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.
disk media record
A reference to a physical disk This record can be thought of
as a physical disk identifier for the disk Disk media
records are configuration records that provide a name with
up to 31 characters (known as the disk media name or DM
name), which you can 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 VxVM.
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.
host ID A name, usually assigned by the administrator, 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. To allow for
system failures that do not clear the host ID, the vxdisk
- 3 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
clearimport operation can be used to clear the host ID
stored on a disk.
If a disk is a member of a disk group and has a host ID that
matches a particular host, then that host imports the disk
group as part of system startup.
kernel log
A log kept in the private region on the disk and that is
written by the VERITAS Volume Manager 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 vxconfigd can be
guaranteed to detect the state changes even in the event of
a system failure.
layered volume
A virtual volume that is used and managed directly by VxVM,
not by a user. Note that currently a layered volume
provides storage for only one upper-level volume.
Layered volumes allow VxVM to implement the following
features:
+ Striped mirrors and concatenated mirrors are new types of
volume layouts that are less likely to fail and that
provide faster recovery times because there is less data
to recover (one column or part of a column versus the
whole volume).
+ Online relayout lets you change the volume layout while
the volume is online. See the vxassist(1M) and
vxrelayout(1M) manual pages for more information.
+ RAID-5 subdisk moves and RAID-5 snapshots (see
vxassist(1M)).
plex A copy of a volume's logical data address space, also called
a mirror. A volume can have up to 32 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, concatenated, or RAID-5 organization
(layout).
plex consistency
If the plexes of a volume contain different data, then the
plexes are said to be inconsistent. This is only a problem
if VxVM is unaware of the inconsistencies, as the volume can
return differing results for consecutive reads. Plex
- 4 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
inconsistency is a serious compromise of data integrity.
This inconsistency can be 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. Plexes can
also be inconsistent after creation of a mirrored volume, if
the plexes are not first synchronized to contain the same
data. An important part of VERITAS Volume Manager operation
is ensuring 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, the volume can be put into a state such that
reads from one plex are automatically written back to the
other plexes, thus making the data consistent for that
volume offset.
private region
Disks used by VxVM contain two special regions: a private
region and a public region.
The private region of a disk contains various on-disk
structures that are used by VxVM for various internal
purposes. Each private region begins with a disk header
which 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.
public region
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.
RLINK (remote link) A representation of a communications link to a
RVG hierarchy at a remote replication site, which contains
information about the link. An RLINK is a primary RLINK if
its parent RVG is the primary RVG containing writable
primary data volumes. Alternatively, a RLINK is a secondary
RLINK if its parent RVG contains read-only data volumes (one
for each data volume that the primary RVG contains). The
vxrlink(1M) command is used to replicate a volume or volumes
to any number of remote sites. The primary RVG has one RLINK
record associated with it for each secondary site. A
secondary RVG has only one RLINK record associated with it,
which represents and contains information about the
connection with the corresponding primary RLINK.
root disk group
Each system requires one special disk group, named rootdg,
which is generally the default for most utilities. In
- 5 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
addition to defining the regular disk group information, the
configuration for the root disk group (rootdg) contains
local information that is specific to a disk group and that
is not intended to be movable between systems.
RVG (replicated volume group) A virtual device that
hierarchically contains one or more data volume records, a
log volume record called a Storage Replicator Log (SRL), and
one (or more for primary RVGs) RLINK records. It must be
associated as a parent of the data volume records in order
for those data volumes to be replicated to other sites which
may be located across a LAN or WAN. In order to actively
replicate a data volume, an RVG must have at least one data
volume child (the volume to be replicated), exactly one SRL
volume child (a volume to SRL data volume writes before they
are transmitted to RLINKs), and at least one RLINK child
(which represents a connection to an RVG hierarchy at a
remote replication site). An RVG can be either a primary or
a secondary, depending on whether its data volumes are
considered to contain the primary copies of data or whether
the data volumes are considered to be read-only copies of
the data. Secondary RVGs contain one SRL volume, one RLINK,
and the same number of data volumes as the primary RVG
contains.
SRL volume [Toc] [Back]
(storage replicator log volume) A volume being used as a
child of an RVG. The SRL volume contains temporary copies of
data intended to be written from (primary) or to (secondary)
sibling data volumes. The SRL volume also contains meta
data, such as connection information, about the RVG and
RLINK with which the SRL volume is associated. The primary
SRL volume is used to log SRL data while either in
asynchronous mode, or during network outages while in
synchronous mode. A secondary RVG must also have an SRL
volume associated with it.
striped plex
A plex that scatters data evenly across each of its
associated subdisks. A plex has a characteristic number of
stripe columns (consisting of associated subdisks) and a
characteristic stripe unit size. The stripe unit size
defines how data with a particular address is allocated to
one of the associated subdisks. Given a stripe unit size of
64 blocks and two stripe columns, the first group of 64
blocks is allocated to the first subdisk, the second group
of 64 blocks is allocated to the second subdisk, the third
group to the first subdisk, and so on.
subdisk A region of storage allocated on a disk for use with a
volume. Subdisks are associated to volumes through plexes.
- 6 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
One or more subdisks are laid out to form plexes based on
the plex layout (striped, concatenated, or RAID-5). Subdisks
are defined relative to disk media records.
volboot file
The volboot file is a special file (usually stored in
/etc/vx/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.
volume A virtual disk device that looks to applications and file
systems like a regular disk device. Volumes present block
and raw device interfaces that are compatible in their use
with disk devices. However, a volume is a virtual device
that can be mirrored, spanned across disk drives, moved to
use different storage, and striped using administrative
commands. The configuration of a volume can be changed,
using VERITAS Volume Manager utilities, without causing
disruption to applications or file systems that are using
the volume.
CONVENTIONS [Toc] [Back]
VxVM employs certain conventions to provide a degree of similarity
between various operations. The conventions are used in the following
areas:
+ Disk Group Selection
+ Standard Length Numbers
+ Command Syntax
Disk Group Selection [Toc] [Back]
Most commands operate upon only one disk group per invocation. Each
disk group has a separate configuration from every other disk group
and it is possible for two disk groups to contain two objects that
have the same name. This can happen, in particular, if a disk group
is moved from one system to another. However, most utilities make no
attempt to ensure that names between disk groups are unique, so name
collisions can occur.
- 7 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
System administrators who try to avoid name collisions should be able
to use most of the utilities without having to specify disk groups
except when creating objects. Administrators cannot use singlecommand
invocations that reference objects in more than one disk
group, but disk groups are selected automatically, based on objects
specified in the command.
The standard rules that most commands use for selecting the disk group
for a command are as follows:
+ Given a particular set of object names specified on the command,
look for the disk group of each object. If all objects are in the
same disk group, use that disk group. If any named object is not
unique between all disk groups, and if one of those object names is
not in the rootdg disk group, then fail.
+ To force use of a particular disk group, use -g diskgroup to
indicate the group. Non-unique names do not cause errors when a
disk group is specified explicitly. The diskgroup specification is
either a disk group ID or a disk group name.
+ A special case is provided for the rootdg disk group. Any set of
objects in the rootdg disk group can be specified without
specifying -g rootdg, even if the given object name is used in
another disk group.
If a set of object names is given on the command line, and if some
are unique but some are not unique, then the command still fails
according to the rules listed above.
Standard Length Numbers [Toc] [Back]
Many basic properties of objects that are managed by VxVM require
specification of lengths, either as a pure object length or as an
offset relative to some other object.
VxVM supports volume lengths up to 2^63-1 disk sectors when using
VERITAS-specific ioctl calls. However, system calls such as seek,
lseek, read and write are limited to a maximum offset that is
determined by the operating system. For a system that supports large
files, this is usually 2^63-1 bytes. Otherwise, the maximum offset
value is usually 2^31-1 bytes (1 byte less than 2 terabytes).
VxVM provides a uniform syntax for representing large numbers, and
uses suffixes to provide convenient multipliers. Numbers can be
specified in decimal, octal, or hexadecimal. For convenience, numbers
can be specified as a sum of several numbers.
- 8 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
A hexadecimal (base 16) number is introduced using a prefix of 0x.
For example, 0xfff is the same as decimal 4095. An octal (base 8)
number is introduced using a prefix of 0. For example, 0177777 is the
same as decimal 65535.
A number can be followed by a single-character suffix to indicate a
multiplier for the number. A length number with no suffix character
represents a count of standard disk sectors. The length of a standard
disk sector can vary between systems; it is typically 512 bytes or
1024 bytes. On systems where disks can have different sector sizes,
one of the sector sizes is chosen as the ``standard'' size. Supported
suffix characters are:
b (Blocks) Multiply the length by 1024 bytes.
g (Gigabytes) Multiply the length by 1,073,741,824 (1024M)
bytes.
k (Kilobytes) Multiply the length by 1024 bytes.
m (Megabytes) Multiply the length by 1,048,576 (1024K) bytes.
s (Sectors) Multiply the length by the standard sector size.
This is the default unit if no suffix is specified.
Numbers are represented internally as an integer number of sectors.
As a result, if the standard disk sector size is larger than 512
bytes, numbers can be specified that need to be rounded to a sector.
Rounding is always done to the next lowest, not the nearest, multiple
of the sector size.
Because the letter b is a valid hexadecimal character, there is a
special case for the b suffix where a single blank character can
separate a number from the b suffix character. Use of a blank within
a number, when invoking commands from the shell, usually requires
quoting the number. For example:
vxassist make vol01 "0x1000 b"
Numbers can be added or subtracted by separating two or more numbers
by a plus or minus sign, respectively. A plus sign is optional. The
following is an example:
1023g+1023m+1023k+1
In output, VxVM reports lengths in sectors, with no suffix character.
Case is ignored in length specification. Hexadecimal numbers and
suffix characters can be specified using any reasonable combination of
- 9 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
uppercase and lowercase letters.
Utility Syntax [Toc] [Back]
Most utilities in VxVM provide more than one operation, with
operations grouped into utilities primarily by object type. Utilities
that provide multiple operations are typically invoked with the
following form:
utility_name [ options ] keyword [ operands ]
utility_name is the name of the VERITAS Volume Manager command and
keyword specifies the specific operation to perform. Any options that
are introduced in the standard -letter form precede the operation
keyword. This is in keeping with standard System V UNIX utility
syntax, which provides for a set of options as the first arguments to
a command, followed by any non-option operands. The keyword is
considered an operand under standard System V syntax.
All VM utilities provide an extended usage message that lists all the
options and operation keywords supported by the utility. Most VM
utilities alsodisplay a usage message if you enter an invalid option.
For utilities that are keyword-based, you can display this extended
usage message the keyword help or a question mark (?). Utilities that
use operands for something other than operation selection provide a
reserved option of -H to display the extended usage information.
RECORD TYPES [Toc] [Back]
Disk group configurations contain eight types of records:
+ Disk Access Records
+ Disk Group Records
+ Disk Media Records
+ Plex Records
+ RLINK Records
- 10 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
+ RVG Records
+ Subdisk Records
+ Volume Records
Disk access records are specific to the root disk group and are stored
in configurations only because there is no other convenient place to
store them; otherwise, they are logically separate from all disk
groups. Because they are specific and meaningful to the local system
only, the logical place for their storage is the rootdg since that is
the only disk group guaranteed to exist on the system.
Disk Access Records [Toc] [Back]
Disk access records define an address, or access path, that can be
used to access a disk. The list of all disk access records defines
the list of all disk addresses that VxVM can use to locate physical
disks. Disk access records do not define specific physical disks,
since physical disks can be moved on a system. When a physical disk
is moved, a different disk access record may be necessary to locate
it.
Disk access records are stored in the rootdg disk group configuration.
Unlike all other record types, the names of disk access records can
conflict with the names of other records. For example, a specialty
disk (such as a RAM disk) can use the same name for both the disk
access record and the disk media record that points to it. It is
typically advisable to use different names for the access and media
records, to avoid additional confusion if disks are moved.
Disk access records can be defined explicitly. Some (sometimes all)
disk access records may be configured automatically by VxVM, based on
available information in the operating system. Such automaticallyconfigured
disks are not stored persistently in the on-disk root disk
group configuration, but are instead regenerated every time VxVM
starts up.
Disk access records have the following fundamental attributes:
disk access name
The name of the disk access record is typically a disk
address. Disk access names are usually of the form c#t#d#,
indicating use of the entire disk on controller c#, with
SCSI target ID t#, and logical unit d#.
VxVM 3.2 introduced an alternative enclosure-based naming
scheme, which uses disk access names of the form
- 11 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
enclosurename_disk# where enclosurename is the logical
enclosure name, and disk# is the number of the disk in the
enclosure. For example, enc0_0 refers to the first disk in
the enclosure enc0.
Other systems are likely to have different conventions for
disk access name.
type Each disk access record has a type, which identifies key
characteristics of VxVM's interaction with the disk.
Available types are: simple, and nopriv. See vxdisk(1M) for
more information on disk types. Typically, most or all of
the disks are of type simple. It may be desirable to create
specialty disks (such as RAM disks) with type nopriv.
If the physical disk represented by the disk access record is
associated with a disk media record, then the following fields are
defined:
disk group name
The name of the disk group containing the disk media record.
disk media name
The name of the disk media record that points to the
physical disk.
Additional attributes can be added, arbitrarily, by disk types. See
vxdisk(1M) for a list of additional attributes defined by the standard
disk types.
Disk Group Records [Toc] [Back]
Disk group records define several different types of names for a disk
group. The different types of names are:
alias name
This 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 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 can be 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.
disk group ID
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 VxVM
- 12 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
does not confuse two disk groups which were created with the
same name.
real name This is the name of the disk group, as 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.
Disk Media Records [Toc] [Back]
Disk media records define a specific disk within a disk group. The
name of a disk media record (the disk media name) is assigned when a
disk is first added to a disk group (using the vxdg adddisk
operation). Disk media records can be assigned to specific physical
disks by associating the disk media record with the current disk
access record for the physical disk.
Disk media records have the following fundamental attributes:
disk access name
The disk access name that is currently used to access the
physical disk referenced by the disk ID. If the disk ID is
defined, but no physical disk with that ID could be found,
the disk access name is clear. A disk where the physical
disk could not be found is considered to be in the NODAREC,
or inaccessible, state. A disk can become inaccessible
either because the indicated disk is not currently attached
to the system, or because I/O failures on the physical disk
prevented VxVM from identifying or using the physical disk.
disk ID A 64-byte unique identifier representing the physical disk
to which the media record is associated. This can be
cleared to indicate that the disk is considered in the
removed state. A removed disk has no current association
with any physical disk.
A disk media record that has an active association with a physical
disk (both the disk ID and the disk access name attributes are
defined), inherits several properties from the underlying physical
disk. These attributes are taken from the disk header, which is
stored in the private region of the disk. These inherited attributes
are:
atomic I/O size
This is the fundamental I/O size for the disk, in bytes,
also known as the sector size. All I/O operations to this
disk must be multiples of this size. VxVM requires that all
disks have the same sector size. On most systems, this size
is 1024 bytes.
private length
The length of the region of the physical disk that is
- 13 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
reserved for storing private VERITAS Volume Manager
information.
public length
The length of the region of the physical disk that is
available for subdisk allocations.
Plex Records [Toc] [Back]
Plex records define the characteristics of a particular plex of a
volume. A plex can be in either an associated state or a dissociated
state. In the dissociated state, the plex is not a part of a volume.
A dissociated plex cannot be accessed in any way. An associated plex
can be accessed through the volume.
Plexes have the following fundamental attributes:
comment An administrator-assigned string of up to 40 characters that
can be set and changed using the vxedit utility. VxVM does
not interpret the comment field. The comment cannot contain
newline characters.
condition flags
Various condition flags are defined for the plex that define
state which is recognized automatically, rather than managed
by the volume usage type. Defined flags are:
IOFAIL The plex was detached as a result of an I/O
failure detected during normal volume I/O. The
plex is out-of-date with respect to the volume,
and in need of complete recovery. However, this
condition also indicates a likelihood that one of
the disks in the system should be replaced.
NODAREC No physical disk could be found corresponding to
the disk ID in the disk media record for one of
the subdisks associated with the plex. The plex
cannot be used until the condition is fixed or the
affected subdisk is dissociated.
RECOVER A disk for one of the disk media records was
replaced or was reattached too late to prevent the
plex from becoming out-of-date with respect to the
volume. The plex requires complete recovery from
another plex in the volume to synchronize the plex
with the correct contents of the volume.
REMOVED One of the disk media records was put into the
removed state through explicit administrative
action. The plex cannot be used until the disk is
replaced or the affected subdisk is dissociated.
- 14 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
contiguous length
The offset of the first block in the plex address space that
is not backed by a subdisk. If the plex has no holes, the
contiguous length matches the plex length. If the
contiguous length is equal to or greater than the length of
the associated volume, the plex is considered complete,
otherwise it is sparse.
I/O mode Each plex is in read-write, read-only, or write-only mode.
This mode affects read and write operations directed to the
volume, if the plex is enabled. For read-write and readonly
modes, volume read operations can be directed to the
plex. For read-write and write-only modes, volume write
operations are directed to the plex.
Plexes are normally in read-write mode. Write-only mode is
used to recover a plex that failed, and whose contents have
thus become out-of-date with respect to the volume. It is
also used when attaching a new plex to a volume. In writeonly
mode, writes to the volume update the plex, causing
written regions to be up-to-date. Typically, a set of
special copy operations is used to update the remainder of
the plex.
layout The organization of associated subdisks with respect to the
plex address space. The layout is striped, concatenated, or
RAID-5.
length The length of a plex is the offset of the last subdisk in
the plex plus the length of that subdisk. In other words,
the length of the plex is defined by the last block in the
plex address space that is backed by a subdisk. This value
may or may not relate to the length of the volume, depending
on whether the plex is completely contiguously allocated.
log subdisk
Each plex can have at most one associated log subdisk. A
log subdisk is used with the dirty region logging feature to
improve the time required to recover consistency of a volume
after a system failure.
plex kernel state
Each plex is either enabled, disabled, or detached. When
enabled, normal read and write operations from the volume
can be directed to the plex. When disabled, no I/O
operations are applied to the plex. When detached, normal
volume I/O are not directed to the plex.
I/O failures encountered during normal volume I/O may move
the enabled state for a plex directly from enabled to
detached. See the description of volume exception policies
- 15 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
(earlier in this manual page) for more information.
subdisks Each plex has zero or more associated subdisks. Subdisks
are associated at offsets relative to the beginning of the
plex address space. Subdisks for concatenated plexes may
not cover the entire length of the plex, in which case they
leave holes in the plex. A plex that is not as long as the
volume to which it is associated is considered to have a
hole extending from the end of the plex to the end of the
volume. A plex with a hole is considered incomplete, and is
sometimes called sparse.
usage-type state
Volume usage types maintain a private state field related to
the the operations that have been performed on the plex, or
to failure conditions that have been encountered. This
state field contains a string of up to 14 characters.
volatile state
A plex is considered to have ``volatile'' contents if the
disk for any of the plex's subdisks is considered to be
volatile. The contents of a volatile disk are not presumed
to survive a system reboot. The contents of a volatile plex
are always considered out-of-date after a recovery and in
need of complete recovery from another plex.
RLINK Records [Toc] [Back]
RLINK records define the characteristics of a particular RLINK of an
RVG. An RLINK can be in either an associated or dissociated state. In
the dissociated state, the RLINK is not part of any RVG. An associated
RLINK can be accessed through the RVG.
RLINK have the following fundamental attributes:
usage type
RLINK are treated internally as if they have a usage-type of
gen, but this distinction is largely irrelevant and exists
merely to be compatible with pre-existing VERITAS Volume
Manager code.
rlink kernel state
Each primary RLINK is either enabled, disabled or detached.
When enabled, normal write operations are forwarded to the
remote RLINK. When disabled, no I/O operations on the RLINK
are allowed. When detached, normal RVG I/O are not directed
to the RLINK, but certain ioctls can be issued against the
RLINK. An enabled RLINK can also be either connected or
disconnected, depending on whether the network connection
between the RLINKs on the primary and secondary nodes is
currently open or not.
- 16 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
usage-type state
RLINKs are treated as having a gen usage-type, and its
usage-type state is a private state field indicating the
state of operations that have been performed on the RLINK,
or failure conditions that have been encountered. This
state field contains a string of up to 14 characters.
synchronous
A field that indicates whether the RLINK should operate in
synchronous or asynchronous mode. In synchronous mode, a
write request to a replicated volume does not complete until
the data has been recorded on the SRL and reached the
secondary node. In asynchronous mode, a write request
completes as soon as the data is recorded on the SRL. The
field may have one of three values:
off mode is asynchronous
override mode is synchronous, but automatically switches to
asynchronous if the rlink becomes inactive due to
a disconnection or administrative action
fail mode is synchronous. If synchronous=fail is set
and an administrator detaches the Primary RLINK,
writes to the RVG are not failed. However, if an
RLINK becomes inactive for any other reason,
including an administrative detach of the
Secondary RLINK, subsequent write requests are
failed with an EIO error.
local_host
RLINKs have a host_name attribute that contains the name of
the local host machine. Needed to support private networks.
remote_host
RLINKs have a remote_host attribute that contains the name
of the remote host machine from (primary) or to (secondary)
which replication takes place.
remote_dg RLINKs have a remote_rlink attribute that contains the name
of the diskgroup on the remote machine.
remote_rlink
RLINKs have a remote_rlink attribute that contains the name
of the RLINK counterpart on the remote machine.
comment An administrator-assigned string of up to 40 characters that
can be set and changed using the vxedit utility. VxVM does
not interpret the comment field. The comment cannot contain
newline characters.
- 17 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
latencyprot
A field that indicates whether latency protection is enabled
for the RLINK. Latency protection prevents a RLINK from
having more than a preset number of outstanding requests.
All requests which have not been written to the remote data
volume are counted as outstanding. If latency protection is
enabled, then when the number of outstanding requests
reaches latency_high_mark, throttling is enabled. This
causes all new write requests to stall until throttling is
disabled. Throttling is not disabled until the number of
outstanding requests is reduced to latency_low_mark. The
field may have one of three values:
off latency protection is disabled
override latency protection is enabled, but is
automatically disabled if the RLINK becomes
inactive due to a disconnection or administrative
action
fail latency protection is enabled. If the RLINK
becomes inactive for any reason, and the
latency_high_mark is reached, subsequent write
requests are failed with an EIO error.
srlprot A field that indicates whether SRL protection is enabled for
the RLINK. SRL protection prevents an RLINK from overflowing
the SRL, which causes the RLINK to disconnect. If the RLINK
has SRL protection enabled, and the next write request would
cause the RLINK to overflow the SRL, then throttling is
enabled. This causes all new write requests to stall until
throttling is disabled. Throttling is not disabled until a
predetermined amount of space is available on the SRL. The
exception to this is when the autodcm mode is set, in which
case, DCM protection is enabled as soon as the SRL overflows
and incoming write requests are not stalled. The field may
have one of five values:
off SRL protection is disabled
override SRL protection is enabled, but will automatically
be disabled if the RLINK becomes inactive due to a
disconnection or administrative action
fail SRL protection is enabled. If the RLINK becomes
inactive for any reason, and SRL overflow is
imminent, subsequent write requests are failed
with an EIO error.
autodcm SRL protection is enabled. This is the default
option for srlprot. If an RLINK begins to
- 18 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
overflow the SRL, DCM protection is activated.
dcm SRL protection is enabled. This differs from the
"autodcm" protection in that the DCM protection is
activated only when the RLINKs disconnect. When
the RLINKs are connected, incoming writes are
throttled as described above.
Note: When DCM protection is activated, the DCMs are used to record
the regions that change on the data volumes. The vxrvg command can be
used to resynchronize the images when the RLINKs are connected. It
should be noted that using DCM to resynchronize an image makes the
image inconsistent until the resynchronization completes.
latency_high_mark
Maximum number of outstanding requests when latency
protection is enabled.
latency_low_mark
After latency throttling is enabled, the number of
outstanding requests must drop to this before it is
disabled.
RVG Records [Toc] [Back]
RVG records define the characteristics of particular RVG devices. The
name of an RVG record defines the node name used for files in the
/dev/vx/dsk and /dev/vx/rdsk directories. The block device for a
particular RVG (which is unused in the current implementation) has the
path:
/dev/vx/dsk/groupname/rvg
where groupname is the name assigned by the administrator to the disk
group containing the RVG. Note that the block device for a child data
volume, not the RVG itself, can be used as an argument to the mount
command (see mount(2)). The raw device for an RVG, typically used for
issuing I/O control operations (see ioctl(2)), has the path:
/dev/vx/rdsk/groupname/rvg
For convenience, RVGs assigned to the root disk group are accessible
under the rootdg subdirectories of /dev/vx/dsk and /dev/vx/rdsk, but
are also under /dev/vx/dsk/rvg and /dev/vx/rdsk/rvg. Accesses to a
data volume associated with a primary RVG device are internally
directed to the RVG so that replication can take place. The RVG device
nodes do not support the read(2) and write(2) system calls.
- 19 - Formatted: January 24, 2005
vxintro(1M) VxVM 3.5 vxintro(1M)
1 Jun 2002
RVGs have the following fundamental attributes:
usage type
RVGs are treated internally as if they have a usage-type of
gen, but this distinction is largely irrelevant and exists
merely to be compatible with pre-existing VERITAS Volume
Manager code.
rvg kernel state
Each primary RVG is either enabled, disabled or detached.
When enabled, normal read and write operations are allowed
on the child data volumes (assuming the underlying data
volumes themselves are enabled) and those accesses are
reflected to the data volumes as well as to any active
RLINKs. When disabled, no access to the data volumes or any
of its associated RLINKs is allowed. When detached, some
ioctls can be used by utilities to operate on the RVG.
usage-type state
RVGs are treated as having a gen usage-type, and its usagetype
state is a private state field indicating the state of
operations that have been performed on the RVG, or failure
conditions that have been encountered. This state field
contains a string of up to 14 characters.
datavols List of data volumes associated with the RVG.
srl Each RVG has one associated SRL volume.
rlink Each primary RVG has between zero and thirty-two associated
RLINK. Each secondary RVG can have no more than one
associated RLINK.
comment An administrator-assigned string of up to 40 characters that
can be set and changed using the vxedit utility. VxVM does
not interpret the comment field. The comment cannot contain
newline characters.
user|group|mode
These attributes are the user, group and file permission
modes used for the RVG device nodes. The user and group are
normally root. The mode usually allows read and write
permission to the owner, and no access by other users.
Subdisk Records [Toc] [Back]
Subdisk records define a region of disk, allocated from a disk's
public region. Subdisks have very little state associated with them,
other than the configuration state that defines which region of disk
the subdisk occupies. Subdisks cannot overlap each other, either in
|
