softraid0 at root
device emulates a Host Bus
Adapter (HBA) that provides RAID and other I/O related services. The
device provides a scaffold to
implement more complex I/O transformation disciplines. For example, one can
tie chunks together into a mirroring discipline. There really is no limit on
what type of discipline one can write as long as it fits the SCSI model.
supports a number of
. A discipline is a collection of
functions that provides specific I/O functionality. This includes I/O path,
bring-up, failure recovery, and statistical information gathering. Essentially
a discipline is a lower level driver that provides the I/O transformation for
the softraid device.
is a virtual disk device that is made up
of a collection of chunks.
is a partition or storage area of fstype
used to alter the fstype.
supports the following
- RAID 0
- A striping discipline. It segments data over
a number of chunks to increase performance. RAID 0 does not provide for
data loss (redundancy).
- RAID 1
- A mirroring discipline. It copies data across
more than one chunk to provide for data loss. Read performance is
increased, though at the cost of write speed. Unlike traditional RAID 1,
softraid supports the use of more than
two chunks in a RAID 1 setup.
- RAID 5
- A striping discipline with floating parity
across all chunks. It stripes data across chunks and provides parity to
prevent data loss of a single chunk failure. Read performance is
increased; write performance does incur additional overhead.
- An encrypting discipline. It encrypts data on
a single chunk to provide for data confidentiality. CRYPTO does not
- A concatenating discipline. It writes data to
each chunk in sequence to provide increased capacity. CONCAT does not
may be used to install
in the boot
storage area of the
support is currently limited to the CRYPTO and RAID 1 disciplines on amd64,
i386, and sparc64 platforms. On sparc64, bootable chunks must be RAID
partitions using the letter ‘a’. At the
softraid volumes have names beginning with ‘sr’ and can be
booted from like a normal disk device. CRYPTO volumes will require a
decryption passphrase or keydisk at boot time.
An example to create a 3 chunk RAID 1 from scratch is as follows:
Initialize the partition tables of all disks:
# fdisk -iy wd1
# fdisk -iy wd2
# fdisk -iy wd3
Now create RAID partitions on all disks:
# printf "a\n\n\n\nRAID\nw\nq\n\n" | disklabel -E wd1
# printf "a\n\n\n\nRAID\nw\nq\n\n" | disklabel -E wd2
# printf "a\n\n\n\nRAID\nw\nq\n\n" | disklabel -E wd3
Assemble the RAID volume:
# bioctl -c 1 -l /dev/wd1a,/dev/wd2a,/dev/wd3a softraid0
The console will show what device was added to the system:
scsibus0 at softraid0: 1 targets
sd0 at scsibus0 targ 0 lun 0: <OPENBSD, SR RAID 1, 001> SCSI2
sd0: 1MB, 0 cyl, 255 head, 63 sec, 512 bytes/sec, 3714 sec total
It is good practice to wipe the front of the disk before using it:
# dd if=/dev/zero of=/dev/rsd0c bs=1m count=1
Initialize the partition table and create a filesystem on the new RAID volume:
# fdisk -iy sd0
# printf "a\n\n\n\n4.2BSD\nw\nq\n\n" | disklabel -E sd0
# newfs /dev/rsd0a
The RAID volume is now ready to be used as a normal disk device. See
information on configuration of RAID sets.
At the boot(8)
load the /bsd kernel from the RAID volume:
driver first appeared in
The driver relies on underlying hardware to properly fail chunks.
The RAID 1 discipline does not initialize the mirror upon creation. This is by
design because all sectors that are read are written first. There is no point
in wasting a lot of time syncing random data.
The RAID 5 discipline does not initialize parity upon creation, instead parity
is only updated upon write.
Currently there is no automated mechanism to recover from failed disks.
Certain RAID levels can protect against some data loss due to component failure.
RAID is not
a substitute for good backup