md.tab(4)
NAME
md.tab, md.cf - Solaris Volume Manager utility files
SYNOPSIS
/etc/lvm/md.tab
/etc/lvm/md.cf
DESCRIPTION
The file /etc/lvm/md.tab can be used by metainit(1M) and
metadb(1M) to configure metadevices, hot spare pools, and
metadevice state database replicas in a batch-like mode.
Solaris Volume Manager does not store configuration informa-
tion in the /etc/lvm/md.tab file. You can use metainit -p
/etc/lvm/md.tab to create this file. Edit it by hand using
the instructions in md.tab.4. Similarly, if no hot spares
are in use, the cp md.cf md.tab command generates an accept-
able version of the md.tab file, with the editing caveats
previously mentioned.
When using the md.tab file, each metadevice, hot spare pool,
or state database replica in the file must have a unique
entry. Entries can include the following: simple metadevices
(stripes, concatenations, and concatenations of stripes);
mirrors, trans metadevices, soft partitions, and RAID5 meta-
devices; hot spare pools; and state database replicas.
Because md.tab contains only entries that you enter in it,
do not rely on the file for the current configuration of
metadevices, hot spare pools, and replicas on the system at
any given time.
Tabs, spaces, comments (by using a pound sign, #), and con-
tinuation of lines (by using a backslash-newline), are
allowed.
Typically, you set up metadevices according to information
specified on the command line by using the metainit command.
Likewise, you set up state database replicas with the metadb
command.
An alternative to the command line is to use the md.tab
file. Metadevices and state database replicas can be speci-
fied in the md.tab file in any order, and then activated in
a batch-like mode with the metainit and metadb commands.
If you edit the md.tab file, you specify one complete confi-
guration entry per line. Metadevices are defined using the
same syntax as required by the metainit command. You then
run the metainit command with either the -a option, to
activate all metadevices in the md.tab file, or with the
metadevice name corresponding to a specific configuration
entry.
metainit does not maintain the state of the volumes that
would have been created when metainit is run with both the
-a and -n flags. If a device d0 is created in the first line
of the md.tab file, and a later line in md.tab assumes the
existence of d0, the later line will fail when metainit -an
runs (even if it would succeed with metainit -a).
State database replicas are defined in the /etc/lvm/md.tab
file as follows: mddb number options [ slice... ] Where mddb
number is the characters mddb followed by a number of two or
more digits that identifies the state database replica.
slice is a physical slice. For example: mddb05
/dev/dsk/c0t1d0s2. The file /etc/lvm/md.cf is a backup of
the configuration used for disaster recovery. Whenever the
Volume Manager configuration is changed, this file is
automatically updated (except when hot sparing occurs). You
should not directly edit this file.
Limitations
Recursive mirroring is not allowed; that is, a mirror cannot
appear in the definition of another mirror.
Recursive logging is not allowed; that is, a trans metadev-
ice cannot appear in the definition of another metadevice.
Stripes and RAID5 metadevices must contains slices or soft
partitions only.
Mirroring of RAID5 metadevices is not allowed.
Soft partitions can be built directly on slices or can be
the top level (accessible by applications directly), but
cannot be in the middle, with other metadevices above and
below them.
EXAMPLES
Example 1: Concatenation
All drives in the following examples have the same size of
525 Mbytes.
This example shows a metadevice, /dev/md/dsk/d7, consisting
of a concatenation of four disks.
#
# (concatenation of four disks)
#
d7 4 1 c0t1d0s0 1 c0t2d0s0 1 c0t3d0s0 1 c0t4d0s0
The number 4 indicates there are four individual stripes in
the concatenation. Each stripe is made of one slice, hence
the number 1 appears in front of each slice. Note that the
first disk sector in all of the above devices contains a
disk label. To preserve the labels on devices
/dev/dsk/c0t2d0s0, /dev/dsk/c0t3d0s0, and /dev/dsk/c0t4d0s0,
the metadisk driver must skip at least the first sector of
those disks when mapping accesses across the concatenation
boundaries. Since skipping only the first sector would
create an irregular disk geometry, the entire first cylinder
of these disks will be skipped. This allows higher level
file system software to optimize block allocations
correctly.
Example 2: Stripe
This example shows a metadevice, /dev/md/dsk/d15, consisting
of two slices.
#
# (stripe consisting of two disks)
#
d15 1 2 c0t1d0s2 c0t2d0s2 -i 32k
The number 1 indicates that one stripe is being created.
Because the stripe is made of two slices, the number 2 fol-
lows next. The optional -i followed by 32k specifies the
interlace size will be 32 Kbytes. If the interlace size were
not specified, the stripe would use the default value of 16
Kbytes.
Example 3: Concatenation of Stripes
This example shows a metadevice, /dev/md/dsk/d75, consisting
of a concatenation of two stripes of three disks.
#
# (concatenation of two stripes, each consisting of three disks)
#
d75 2 3 c0t1d0s2 c0t2d0s2 c0t3d0s2 -i 16k \
3 c1t1d0s2 c1t2d0s2 c1t3d0s2 -i 32k
On the first line, the -i followed by 16k specifies that the
stripe's interlace size is 16 Kbytes. The second set speci-
fies the stripe interlace size will be 32 Kbytes. If the
second set did not specify 32 Kbytes, the set would use
default interlace value of 16 Kbytes. The blocks of each set
of three disks are interlaced across three disks.
Example 4: Mirroring
This example shows a three-way mirror, /dev/md/dsk/d50, con-
sisting of three submirrors. This mirror does not contain
any existing data.
#
# (mirror)
#
d50 -m d51
d51 1 1 c0t1d0s2
d52 1 1 c0t2d0s2
d53 1 1 c0t3d0s2
In this example, a one-way mirror is first defined using the
-m option. The one-way mirror consists of submirror d51. The
other two submirrors, d52 and d53, are attached later using
the metattach command. The default read and write options
in this example are a round-robin read algorithm and paral-
lel writes to all submirrors. The order in which mirrors
appear in the /etc/lvm/md.tab file is unimportant.
Example 5: Logging (trans)
This example shows a trans metadevice, /dev/md/dsk/d1, with
mirrors for the master and logging devices. This trans does
not contain any existing data.
#
# (trans)
#
d1 -t d10 d20
d10 -m d11
d11 1 1 c0t1d0s2
d12 1 1 c0t2d0s2
d20 -m d21
d21 1 1 c1t1d0s2
d22 1 1 c1t2d0s2
In this example, the two mirrors, d10 and d20, are defined
using the -m option. d10 is defined as the master device and
d20 is defined as the logging device for the trans, d1, by
using the -t option. The order in which mirrors or trans
appear in the /etc/lvm/md.tab file is unimportant. The sub-
mirrors d12 and d22 are attached later (using the metattach
command) to the d10 and d20 mirrors.
Example 6: RAID5
This example shows a RAID5 metadevice, d80, consisting of
three slices:
#
# (RAID devices)
#
d80 -r c0t1d0s1 c1t0d0s1 c2t0d0s1 -i 20k
In this example, a RAID5 metadevice is defined using the -r
option with an interlace size of 20 Kbytes. The data and
parity segments will be striped across the slices, c0t1d0s1,
c1t0d0s1, and c2t0d0s1.
Example 7: Soft Partition
This example shows a soft partition, d85, that reformats an
entire 9 GB disk. Slice 0 occupies all of the disk except
for the few Mbytes taken by slice 7, which is space reserved
for a state database replica. Slice 7 will be a minimum of
4Mbytes, but could be larger, depending on the disk
geometry. d85 sits on c3t4d0s0.
Drives are repartitioned when they are added to a diskset
only if Slice 7 is not set up correctly. A small portion of
each drive is reserved in Slice 7 for use by Volume Manager.
The remainder of the space on each drive is placed into
Slice 0. Any existing data on the disks is lost after repar-
titioning. After adding a drive to a diskset, you can
repartition the drive as necessary. However, Slice 7 should
not be moved, removed, or overlapped with any other parti-
tion.
Manually specifying the offsets and extents of soft parti-
tions is not recommended. This example is included for to
provide a better understanding of the file if it is automat-
ically generated and for completeness.
#
# (Soft Partitions)
d85 -p -e c3t4d0 9g
In this example, creating the soft partition and required
space for the state database replica occupies all 9 GB of
disk c3t4d0.
Example 8: Soft Partition
This example shows the command used to re-create a soft par-
tition with two extents, the first one starting at offset
20483 and extending for 20480 blocks and the second extent
starting at 135398 and extending for 20480 blocks:
#
# (Soft Partitions)
#
d1 -p c0t3d0s0 -o 20483 -b 20480 -o 135398 -b 20480
Example 9: Hot Spare
This example shows a three-way mirror, /dev/md/dsk/d10, con-
sisting of three submirrors and three hot spare pools.
#
# (mirror and hot spare)
#
d10 -m d20
d20 1 1 c1t0d0s2 -h hsp001
d30 1 1 c2t0d0s2 -h hsp002
d40 1 1 c3t0d0s2 -h hsp003
hsp001 c2t2d0s2 c3t2d0s2 c1t2d0s2
hsp002 c3t2d0s2 c1t2d0s2 c2t2d0s2
hsp003 c1t2d0s2 c2t2d0s2 c3t2d0s2
In this example, a one-way mirror is first defined using the
-m option. The submirrors are attached later using the
metattach(1M) command. The hot spare pools to be used are
tied to the submirrors with the -h option. In this example,
there are three disks used as hot spares, defined in three
separate hot spare pools. The hot spare pools are given the
names hsp001, hsp002, and hsp003. Setting up three hot spare
pools rather than assigning just one hot spare with each
component helps to maximize the use of hardware. This confi-
guration enables the user to specify that the most desirable
hot spare be selected first, and improves availability by
having more hot spares available. At the end of the entry,
the hot spares to be used are defined. Note that, when using
the md.tab file, to associate hot spares with metadevices,
the hot spare spool does not have to exist prior to the
association. Volume Manager takes care of the order in which
metadevices and hot spares are created when using the md.tab
file.
Example 10: State Database Replicas
This example shows how to set up an initial state database
and three replicas on a server that has three disks.
#
# (state database and replicas)
#
mddb01 -c 3 c0t1d0s0 c0t2d0s0 c0t3d0s0
In this example, three state database replicas are stored on
each of the three slices. Once the above entry is made in
the /etc/lvm/md.tab file, the metadb command must be run
with both the -a and -f options. For example, typing the
following command creates one state database replicas on
three slices:
# metadb -a -f mddb01
FILES
/etc/lvm/md.tab
/etc/lvm/md.cf
SEE ALSO
metaclear(1M), metadb(1M), metadetach(1M), metahs(1M),
metainit(1M), metaoffline(1M), metaonline(1M),
metaparam(1M), metarecover(1M), metareplace(1M),
metaroot(1M), metastat(1M), metasync(1M), metattach(1M),
mddb.cf(4)
Solaris Volume Manager Administration Guide
Man(1) output converted with
man2html