diff options
Diffstat (limited to 'static/freebsd/man4/ccd.4 3.html')
| -rw-r--r-- | static/freebsd/man4/ccd.4 3.html | 173 |
1 files changed, 173 insertions, 0 deletions
diff --git a/static/freebsd/man4/ccd.4 3.html b/static/freebsd/man4/ccd.4 3.html new file mode 100644 index 00000000..fe91f3ca --- /dev/null +++ b/static/freebsd/man4/ccd.4 3.html @@ -0,0 +1,173 @@ +<table class="head"> + <tr> + <td class="head-ltitle">CCD(4)</td> + <td class="head-vol">Device Drivers Manual</td> + <td class="head-rtitle">CCD(4)</td> + </tr> +</table> +<div class="manual-text"> +<section class="Sh"> +<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1> +<p class="Pp"><code class="Nm">ccd</code> — <span class="Nd">Concatenated + Disk driver</span></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1> +<p class="Pp"><code class="Cd">device ccd</code></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1> +<p class="Pp">The <code class="Nm">ccd</code> driver provides the capability of + combining one or more disks/partitions into one virtual disk.</p> +<p class="Pp">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.</p> +<p class="Pp">In order to compile in support for the + <code class="Nm">ccd</code>, you must add a line similar to the following to + your kernel configuration file:</p> +<p class="Pp"></p> +<div class="Bd Bd-indent"><code class="Li">device ccd # concatenated disk + devices</code></div> +<p class="Pp">As of the <span class="Ux">FreeBSD 3.0</span> release, you do not + need to configure your kernel with <code class="Nm">ccd</code> but may + instead use it as a kernel loadable module. Simply running + <a class="Xr">ccdconfig(8)</a> will load the module into the kernel.</p> +<p class="Pp">A <code class="Nm">ccd</code> 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.</p> +<p class="Pp">There is a run-time utility that is used for configuring + <code class="Nm">ccd</code>s. See <a class="Xr">ccdconfig(8)</a> for more + information.</p> +<section class="Ss"> +<h2 class="Ss" id="The_Interleave_Factor"><a class="permalink" href="#The_Interleave_Factor">The + Interleave Factor</a></h2> +<p class="Pp">If a <code class="Nm">ccd</code> is interleaved correctly, a + “striping” effect is achieved, which can increase sequential + read/write performance. The interleave factor is expressed in units of + <code class="Dv">DEV_BSIZE</code> (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 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 + 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 you do + this, but sequential performance is not usually an issue with a multitasking + load.</p> +<p class="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 how I/O is broken up, however, and a value 128 or greater is + recommended.</p> +<p class="Pp"><code class="Nm">ccd</code> has an option for a parity disk, but + does not currently implement it.</p> +<p class="Pp">The best performance is achieved if all component disks have the + same geometry and size. Optimum striping cannot occur with different disk + types.</p> +<p class="Pp">For random-access oriented workloads, such as news servers, a + larger interleave factor (e.g., 65,536) is more desirable. Note that there + is not much <code class="Nm">ccd</code> 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.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="Disk_Mirroring"><a class="permalink" href="#Disk_Mirroring">Disk + Mirroring</a></h2> +<p class="Pp">You can configure the <code class="Nm">ccd</code> to + “mirror” any even number of disks. See + <a class="Xr">ccdconfig(8)</a> for how to specify the necessary flags. For + example, if you have a <code class="Nm">ccd</code> 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 driver will automatically attempt to read + the same sector from the other side of the mirror. Currently + <code class="Nm">ccd</code> uses a dual seek zone model to optimize reads + for a multi-tasking load rather than a sequential load.</p> +<p class="Pp">In an event of a disk failure, you can use <a class="Xr">dd(1)</a> + to recover the failed disk.</p> +<p class="Pp">Note that a one-disk <code class="Nm">ccd</code> is not the same + as the original partition. In particular, this means if you have a file + system on a two-disk mirrored <code class="Nm">ccd</code> and one of the + disks fail, you cannot mount and use the remaining partition as itself; you + have to configure it as a one-disk <code class="Nm">ccd</code>. You cannot + replace a disk in a mirrored <code class="Nm">ccd</code> partition without + first backing up the partition, then replacing the disk, then restoring the + partition.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="Linux_Compatibility"><a class="permalink" href="#Linux_Compatibility">Linux + Compatibility</a></h2> +<p class="Pp">The Linux compatibility mode does not try to read the label that + Linux' <a class="Xr">md(4)</a> driver leaves on the raw devices. You will + have to give the order of devices and the interleave factor on your own. + When in Linux compatibility mode, <code class="Nm">ccd</code> will convert + the interleave factor from Linux terminology. That means you give the same + interleave factor that you gave as chunk size in Linux.</p> +<p class="Pp">If you have a Linux <a class="Xr">md(4)</a> device in + “legacy” mode, do not use the + <code class="Dv">CCDF_LINUX</code> flag in <a class="Xr">ccdconfig(8)</a>. + Use the <code class="Dv">CCDF_NO_OFFSET</code> flag instead. In that case + you have to convert the interleave factor on your own, usually it is Linux' + chunk size multiplied by two.</p> +<p class="Pp">Using a Linux RAID this way is potentially dangerous and can + destroy the data in there. Since <span class="Ux">FreeBSD</span> does not + read the label used by Linux, changes in Linux might invalidate the + compatibility layer.</p> +<p class="Pp">However, using this is reasonably safe if you test the + compatibility before mounting a RAID read-write for the first time. Just + using <a class="Xr">ccdconfig(8)</a> without mounting does not write + anything to the Linux RAID. Then you do a + <code class="Nm">fsck.ext2fs</code> + (<span class="Pa">ports/filesystems/e2fsprogs</span>) on the + <code class="Nm">ccd</code> device using the <code class="Fl">-n</code> + flag. You can mount the file system read-only to check files in there. If + all this works, it is unlikely that there is a problem with + <code class="Nm">ccd</code>. Keep in mind that even when the Linux + compatibility mode in <code class="Nm">ccd</code> is working correctly, bugs + in <span class="Ux">FreeBSD</span>'s <code class="Nm">ex2fs</code> + implementation would still destroy your data.</p> +</section> +</section> +<section class="Sh"> +<h1 class="Sh" id="WARNINGS"><a class="permalink" href="#WARNINGS">WARNINGS</a></h1> +<p class="Pp">If just one (or more) of the disks in a + <code class="Nm">ccd</code> fails, the entire file system will be lost + unless you are mirroring the disks.</p> +<p class="Pp">If one of the disks in a mirror is lost, you should still 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.</p> +<p class="Pp">Changing the interleave or other parameters for a + <code class="Nm">ccd</code> disk usually destroys whatever data previously + existed on that disk.</p> +</section> +<section class="Sh"> +<h1 class="Sh" id="FILES"><a class="permalink" href="#FILES">FILES</a></h1> +<dl class="Bl-tag"> + <dt><span class="Pa">/dev/ccd*</span></dt> + <dd><code class="Nm">ccd</code> device special files</dd> +</dl> +</section> +<section class="Sh"> +<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE + ALSO</a></h1> +<p class="Pp"><a class="Xr">dd(1)</a>, <a class="Xr">ccdconfig(8)</a>, + <a class="Xr">config(8)</a>, <a class="Xr">disklabel(8)</a>, + <a class="Xr">fsck(8)</a>, <a class="Xr">mount(8)</a>, + <a class="Xr">newfs(8)</a></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1> +<p class="Pp">The concatenated disk driver was originally written at the + University of Utah.</p> +</section> +</div> +<table class="foot"> + <tr> + <td class="foot-date">January 23, 2025</td> + <td class="foot-os">FreeBSD 15.0</td> + </tr> +</table> |