mirror of
https://github.com/freebsd/freebsd-src
synced 2024-09-06 17:18:32 +00:00
mdoc(7) police: tidy up the markup.
This commit is contained in:
parent
7b3e3e39c7
commit
328b06b929
Notes:
svn2git
2020-12-20 02:59:44 +00:00
svn path=/head/; revision=97459
|
@ -48,41 +48,43 @@ The
|
|||
driver provides the capability of combining one or more disks/partitions
|
||||
into one virtual disk.
|
||||
.Pp
|
||||
This document assumes that you're familiar with how to generate kernels,
|
||||
This document assumes that you are familiar with how to generate kernels,
|
||||
how to properly configure disks and devices in a kernel
|
||||
configuration file, and how to partition disks.
|
||||
.Pp
|
||||
Note that the
|
||||
.Sq raw
|
||||
.Dq raw
|
||||
partitions of the disks
|
||||
.Pa should not
|
||||
be combined. The kernel will only allow component partitions of type
|
||||
FS_BSDFFS (type
|
||||
.Dq Bx 4.2
|
||||
as shown as
|
||||
.Em should not
|
||||
be combined.
|
||||
The kernel will only allow component partitions of type
|
||||
.Dv FS_BSDFFS (type
|
||||
.Dq Li 4.2BSD
|
||||
as shown by
|
||||
.Xr disklabel 8 ) .
|
||||
.Pp
|
||||
In order to compile in support for the ccd, you must add a line similar
|
||||
In order to compile in support for the
|
||||
.Nm ,
|
||||
you must add a line similar
|
||||
to the following to your kernel configuration file:
|
||||
.Bd -unfilled -offset indent
|
||||
device ccd # concatenated disk devices
|
||||
.Ed
|
||||
.Pp
|
||||
The count argument is how many
|
||||
.Nm Ns 's
|
||||
memory is allocated for a boot time. In this example, no more than 4
|
||||
.Nm Ns s
|
||||
may be configured. As of the
|
||||
.Dl "device ccd # concatenated disk devices"
|
||||
.Pp
|
||||
As of the
|
||||
.Fx 3.0
|
||||
release, you do not need to
|
||||
configure your kernel with ccd but may instead use it as a kernel loadable
|
||||
module. Simply running
|
||||
.Nm ccdconfig
|
||||
configure your kernel with
|
||||
.Nm
|
||||
but may instead use it as a kernel loadable
|
||||
module.
|
||||
Simply running
|
||||
.Xr ccdconfig 8
|
||||
will load the module into the kernel.
|
||||
.Pp
|
||||
A
|
||||
.Nm
|
||||
may be either serially concatenated or interleaved. To serially
|
||||
may be either serially concatenated or interleaved.
|
||||
To serially
|
||||
concatenate the partitions, specify the interleave factor of 0.
|
||||
Note that mirroring may not be used with an interleave factor of 0.
|
||||
.Pp
|
||||
|
@ -97,35 +99,46 @@ If a
|
|||
is interleaved correctly, a
|
||||
.Dq striping
|
||||
effect is achieved, which can increase sequential read/write
|
||||
performance. The interleave factor is expressed in units of DEV_BSIZE
|
||||
(usually 512 bytes). For large writes, the optimum interleave factor
|
||||
performance.
|
||||
The interleave factor is expressed in units of
|
||||
.Dv DEV_BSIZE
|
||||
(usually 512 bytes).
|
||||
For large writes, the optimum interleave factor
|
||||
is typically the size of a track, while for large reads, it is about a
|
||||
quarter of a track.
|
||||
(Note that this changes greatly depending on the
|
||||
number and speed of disks.) For instance, with eight 7,200 RPM drives
|
||||
number and speed of disks.)
|
||||
For instance, with eight 7,200 RPM drives
|
||||
on two Fast-Wide SCSI buses, this translates to about 128 for writes
|
||||
and 32 for reads. A larger interleave tends to work better when the
|
||||
and 32 for reads.
|
||||
A larger interleave tends to work better when the
|
||||
disk is taking a multitasking load by localizing the file I/O from
|
||||
any given process onto a single disk. You lose sequential performance when
|
||||
any given process onto a single disk.
|
||||
You lose sequential performance when
|
||||
you do this, but sequential performance is not usually an issue with a
|
||||
multitasking load.
|
||||
.Pp
|
||||
An interleave factor must be specified when using a mirroring configuration,
|
||||
even when you have only two disks (i.e. the layout winds up being the same
|
||||
no matter what the interleave factor). The interleave factor will determine
|
||||
no matter what the interleave factor).
|
||||
The interleave factor will determine
|
||||
how I/O is broken up, however, and a value 128 or greater is recommended.
|
||||
.Pp
|
||||
CCD has an option for a parity disk, but does not currently implement it.
|
||||
.Nm
|
||||
has an option for a parity disk, but does not currently implement it.
|
||||
.Pp
|
||||
The best performance is achieved if all component disks have the same
|
||||
geometry and size. Optimum striping cannot occur with different
|
||||
geometry and size.
|
||||
Optimum striping cannot occur with different
|
||||
disk types.
|
||||
.Pp
|
||||
For random-access oriented workloads, such as news servers, a larger
|
||||
interleave factor (e.g., 65,536) is more desirable. Note that there
|
||||
isn't much
|
||||
interleave factor (e.g., 65,536) is more desirable.
|
||||
Note that there
|
||||
is not much
|
||||
.Nm
|
||||
can do to speed up applications that are seek-time limited. Larger
|
||||
can do to speed up applications that are seek-time limited.
|
||||
Larger
|
||||
interleave factors will at least reduce the chance of having to seek
|
||||
two disk-heads to read one directory or a file.
|
||||
.Ss Disk Mirroring
|
||||
|
@ -133,15 +146,22 @@ You can configure the
|
|||
.Nm
|
||||
to
|
||||
.Dq mirror
|
||||
any even number of disks. See
|
||||
any even number of disks.
|
||||
See
|
||||
.Xr ccdconfig 8
|
||||
for how to specify the necessary flags. For example, if you have a ccd
|
||||
for how to specify the necessary flags.
|
||||
For example, if you have a
|
||||
.Nm
|
||||
configuration specifying four disks, the first two disks will be mirrored with
|
||||
the second two disks. A write will be run to both sides of
|
||||
the mirror. A read will be run to either side of the mirror depending
|
||||
on what the driver believes to be most optimal. If the read fails,
|
||||
the second two disks.
|
||||
A write will be run to both sides of
|
||||
the mirror.
|
||||
A read will be run to either side of the mirror depending
|
||||
on what the driver believes to be most optimal.
|
||||
If the read fails,
|
||||
the driver will automatically attempt to read the same sector from the
|
||||
other side of the mirror. Currently
|
||||
other side of the mirror.
|
||||
Currently
|
||||
.Nm
|
||||
uses a duel seek zone model to optimize reads for a multi-tasking load
|
||||
rather then a sequential load.
|
||||
|
@ -153,7 +173,8 @@ to recover the failed disk.
|
|||
.Pp
|
||||
Note that a one-disk
|
||||
.Nm
|
||||
is not the same as the original partition. In particular, this means
|
||||
is not the same as the original partition.
|
||||
In particular, this means
|
||||
if you have a filesystem on a two-disk mirrored
|
||||
.Nm
|
||||
and one of the disks fail, you cannot mount and use the remaining
|
||||
|
@ -170,9 +191,12 @@ fails, the entire
|
|||
filesystem will be lost unless you are mirroring the disks.
|
||||
.Pp
|
||||
If one of the disks in a mirror is lost, you should still
|
||||
be able to backup your data. If a write error occurs, however, data
|
||||
read from that sector may be non-deterministic. It may return the data
|
||||
prior to the write or it may return the data that was written. When a
|
||||
be able to back up your data.
|
||||
If a write error occurs, however, data
|
||||
read from that sector may be non-deterministic.
|
||||
It may return the data
|
||||
prior to the write or it may return the data that was written.
|
||||
When a
|
||||
write error occurs, you should recover and regenerate the data as soon
|
||||
as possible.
|
||||
.Pp
|
||||
|
|
Loading…
Reference in a new issue