As described above, Vinum assigns default names to plexes and subdisks, although they may be overridden. Overriding the default names is not recommended: experience with the VERITAS volume manager, which allows arbitrary naming of objects, has shown that this flexibility does not bring a significant advantage, and it can cause confusion.
Names may contain any non-blank character, but it is recommended to restrict them to letters, digits and the underscore characters. The names of volumes, plexes and subdisks may be up to 64 characters long, and the names of drives may be up to 32 characters long.
Vinum objects are assigned device nodes in the hierarchy
/dev/vinum
. The configuration shown above
would cause Vinum to create the following device nodes:
The control devices
/dev/vinum/control
and
/dev/vinum/controld
, which are used
by vinum(8) and the Vinum daemon respectively.
Block and character device entries for each volume.
These are the main devices used by Vinum. The block device
names are the name of the volume, while the character device
names follow the BSD tradition of prepending the letter
r to the name. Thus the configuration
above would include the block devices
/dev/vinum/myvol
,
/dev/vinum/mirror
,
/dev/vinum/striped
,
/dev/vinum/raid5
and
/dev/vinum/raid10
, and the
character devices
/dev/vinum/rmyvol
,
/dev/vinum/rmirror
,
/dev/vinum/rstriped
,
/dev/vinum/rraid5
and
/dev/vinum/rraid10
. There is
obviously a problem here: it is possible to have two volumes
called r and rr,
but there will be a conflict creating the device node
/dev/vinum/rr
: is it a character
device for volume r or a block device
for volume rr? Currently Vinum does
not address this conflict: the first-defined volume will get
the name.
A directory /dev/vinum/drive
with entries for each drive. These entries are in fact
symbolic links to the corresponding disk nodes.
A directory /dev/vinum/volume
with
entries for each volume. It contains subdirectories for
each plex, which in turn contain subdirectories for their
component subdisks.
The directories
/dev/vinum/plex
,
/dev/vinum/sd
, and
/dev/vinum/rsd
, which contain block
device nodes for each plex and block and character device
nodes respectively for each subdisk.
For example, consider the following configuration file:
drive drive1 device /dev/sd1h drive drive2 device /dev/sd2h drive drive3 device /dev/sd3h drive drive4 device /dev/sd4h volume s64 setupstate plex org striped 64k sd length 100m drive drive1 sd length 100m drive drive2 sd length 100m drive drive3 sd length 100m drive drive4
After processing this file, vinum(8) creates the following
structure in /dev/vinum
:
brwx------ 1 root wheel 25, 0x40000001 Apr 13 16:46 Control brwx------ 1 root wheel 25, 0x40000002 Apr 13 16:46 control brwx------ 1 root wheel 25, 0x40000000 Apr 13 16:46 controld drwxr-xr-x 2 root wheel 512 Apr 13 16:46 drive drwxr-xr-x 2 root wheel 512 Apr 13 16:46 plex crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 rs64 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 rsd drwxr-xr-x 2 root wheel 512 Apr 13 16:46 rvol brwxr-xr-- 1 root wheel 25, 2 Apr 13 16:46 s64 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd drwxr-xr-x 3 root wheel 512 Apr 13 16:46 vol /dev/vinum/drive: total 0 lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive1 -> /dev/sd1h lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive2 -> /dev/sd2h lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive3 -> /dev/sd3h lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive4 -> /dev/sd4h /dev/vinum/plex: total 0 brwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 /dev/vinum/rsd: total 0 crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0 crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1 crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2 crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3 /dev/vinum/rvol: total 0 crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64 /dev/vinum/sd: total 0 brwxr-xr-- 1 root wheel 25, 0x20000002 Apr 13 16:46 s64.p0.s0 brwxr-xr-- 1 root wheel 25, 0x20100002 Apr 13 16:46 s64.p0.s1 brwxr-xr-- 1 root wheel 25, 0x20200002 Apr 13 16:46 s64.p0.s2 brwxr-xr-- 1 root wheel 25, 0x20300002 Apr 13 16:46 s64.p0.s3 /dev/vinum/vol: total 1 brwxr-xr-- 1 root wheel 25, 2 Apr 13 16:46 s64 drwxr-xr-x 3 root wheel 512 Apr 13 16:46 s64.plex /dev/vinum/vol/s64.plex: total 1 brwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 s64.p0.sd /dev/vinum/vol/s64.plex/s64.p0.sd: total 0 brwxr-xr-- 1 root wheel 25, 0x20000002 Apr 13 16:46 s64.p0.s0 brwxr-xr-- 1 root wheel 25, 0x20100002 Apr 13 16:46 s64.p0.s1 brwxr-xr-- 1 root wheel 25, 0x20200002 Apr 13 16:46 s64.p0.s2 brwxr-xr-- 1 root wheel 25, 0x20300002 Apr 13 16:46 s64.p0.s3
Although it is recommended that plexes and subdisks should not be allocated specific names, Vinum drives must be named. This makes it possible to move a drive to a different location and still recognize it automatically. Drive names may be up to 32 characters long.
Volumes appear to the system to be identical to disks,
with one exception. Unlike UNIX® drives, Vinum does
not partition volumes, which thus do not contain a partition
table. This has required modification to some disk
utilities, notably newfs(8), which previously tried to
interpret the last letter of a Vinum volume name as a
partition identifier. For example, a disk drive may have a
name like /dev/ad0a
or
/dev/da2h
. These names represent
the first partition (a
) on the
first (0) IDE disk (ad
) and the
eighth partition (h
) on the third
(2) SCSI disk (da
) respectively.
By contrast, a Vinum volume might be called
/dev/vinum/concat
, a name which has
no relationship with a partition name.
Normally, newfs(8) interprets the name of the disk and complains if it cannot understand it. For example:
#
newfs /dev/vinum/concat
newfs: /dev/vinum/concat: can't figure out file system partition
The following is only valid for FreeBSD versions prior to 5.0:
In order to create a file system on this volume, use the
-v
option to newfs(8):
#
newfs -v /dev/vinum/concat
All FreeBSD documents are available for download at http://ftp.FreeBSD.org/pub/FreeBSD/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.