diff options
Diffstat (limited to 'documentation/content/en/articles/vinum/_index.adoc')
| -rw-r--r-- | documentation/content/en/articles/vinum/_index.adoc | 56 |
1 files changed, 36 insertions, 20 deletions
diff --git a/documentation/content/en/articles/vinum/_index.adoc b/documentation/content/en/articles/vinum/_index.adoc index 3fc70ed9b4..0583ae94a7 100644 --- a/documentation/content/en/articles/vinum/_index.adoc +++ b/documentation/content/en/articles/vinum/_index.adoc @@ -6,6 +6,16 @@ description: The vinum Volume Manager in FreeBSD tags: ["vinum", "Volume Manager", "FreeBSD"] --- +//// +The Vinum Volume Manager +By Greg Lehey (grog at lemis dot com) + +Added to the Handbook by Hiten Pandya <hmp@FreeBSD.org> +and Tom Rhodes <trhodes@FreeBSD.org> + +For the FreeBSD Documentation Project +//// + = The vinum Volume Manager :doctype: article :toc: macro @@ -15,20 +25,26 @@ tags: ["vinum", "Volume Manager", "FreeBSD"] :sectnumlevels: 6 :source-highlighter: rouge :experimental: - - -ifeval::["{backend}" == "html5"] -include::shared/en/urls.adoc[] -:imagesdir: ../../../images/articles/vinum/ +:images-path: articles/vinum/ + +ifdef::env-beastie[] +ifdef::backend-html5[] +include::shared/authors.adoc[] +include::shared/mirrors.adoc[] +include::shared/releases.adoc[] +include::shared/attributes/attributes-{{% lang %}}.adoc[] +include::shared/{{% lang %}}/teams.adoc[] +include::shared/{{% lang %}}/mailing-lists.adoc[] +include::shared/{{% lang %}}/urls.adoc[] +:imagesdir: ../../../images/{images-path} +endif::[] +ifdef::backend-pdf,backend-epub3[] +include::../../../../shared/asciidoctor.adoc[] endif::[] - -ifeval::["{backend}" == "pdf"] -include::../../../../shared/en/urls.adoc[] -:imagesdir: ../../../../static/images/articles/vinum/ endif::[] -ifeval::["{backend}" == "epub3"] -:imagesdir: ../../../../static/images/articles/vinum/ +ifndef::env-beastie[] +include::../../../../../shared/asciidoctor.adoc[] endif::[] ''' @@ -52,7 +68,7 @@ This chapter provides an overview of potential problems with traditional disk st [NOTE] ==== -Starting with FreeBSD 5, [.filename]#vinum# has been rewritten in order to fit into the link:{handbook}#geom[GEOM architecture], while retaining the original ideas, terminology, and on-disk metadata. +Starting with FreeBSD 5, [.filename]#vinum# has been rewritten to fit into the extref:{handbook}[GEOM architecture, geom], while retaining the original ideas, terminology, and on-disk metadata. This rewrite is called _gvinum_ (for _GEOM vinum_). While this chapter uses the term [.filename]#vinum#, any command invocations should be performed with `gvinum`. The name of the kernel module has changed from the original [.filename]#vinum.ko# to [.filename]#geom_vinum.ko#, and all device nodes reside under [.filename]#/dev/gvinum# instead of [.filename]#/dev/vinum#. @@ -142,7 +158,7 @@ If one drive fails, the array can continue to operate in degraded mode where a r [[vinum-objects]] == [.filename]#vinum# Objects -In order to address these problems, [.filename]#vinum# implements a four-level hierarchy of objects: +To address these problems, [.filename]#vinum# implements a four-level hierarchy of objects: * The most visible object is the virtual disk, called a _volume_. Volumes have essentially the same properties as a UNIX(R) disk drive, though there are some minor differences. For one, they have no size limitations. * Volumes are composed of _plexes_, each of which represent the total address space of a volume. This level in the hierarchy provides redundancy. Think of plexes as individual disks in a mirrored array, each containing the same data. @@ -170,7 +186,7 @@ As long as at least one plex can provide the data for the complete address range [.filename]#vinum# implements both concatenation and striping at the plex level: * A _concatenated plex_ uses the address space of each subdisk in turn. Concatenated plexes are the most flexible as they can contain any number of subdisks, and the subdisks may be of different length. The plex may be extended by adding additional subdisks. They require less CPU time than striped plexes, though the difference in CPU overhead is not measurable. On the other hand, they are most susceptible to hot spots, where one disk is very active and others are idle. -* A _striped plex_ stripes the data across each subdisk. The subdisks must all be the same size and there must be at least two subdisks in order to distinguish it from a concatenated plex. The greatest advantage of striped plexes is that they reduce hot spots. By choosing an optimum sized stripe, about 256 kB, the load can be evened out on the component drives. Extending a plex by adding new subdisks is so complicated that [.filename]#vinum# does not implement it. +* A _striped plex_ stripes the data across each subdisk. The subdisks must all be the same size and there must be at least two subdisks to distinguish it from a concatenated plex. The greatest advantage of striped plexes is that they reduce hot spots. By choosing an optimum sized stripe, about 256 kB, the load can be evened out on the component drives. Extending a plex by adding new subdisks is so complicated that [.filename]#vinum# does not implement it. <<vinum-comparison, [.filename]#vinum# Plex Organizations>> summarizes the advantages and disadvantages of each plex organization. @@ -468,7 +484,7 @@ For example, a disk drive may have a name like [.filename]#/dev/ad0a# or [.filen These names represent the first partition ([.filename]#a#) on the first (0) IDE disk ([.filename]#ad#) and the eighth partition ([.filename]#h#) on the third (2) SCSI disk ([.filename]#da#) respectively. By contrast, a [.filename]#vinum# volume might be called [.filename]#/dev/gvinum/concat#, which has no relationship with a partition name. -In order to create a file system on this volume, use man:newfs[8]: +To create a file system on this volume, use man:newfs[8]: [source,shell] .... @@ -566,7 +582,7 @@ Each single subdisk within these plexes needs its own `a` partition illusion, fo It is not strictly needed that each of these faked `a` partitions is located at the same offset within its device, compared with other devices containing plexes of the root volume. However, it is probably a good idea to create the [.filename]#vinum# volumes that way so the resulting mirrored devices are symmetric, to avoid confusion. -In order to set up these `a` partitions for each device containing part of the root volume, the following is required: +To set up these `a` partitions for each device containing part of the root volume, the following is required: [.procedure] ==== @@ -578,7 +594,7 @@ In order to set up these `a` partitions for each device containing part of the r .... + [.filename]#vinum# offsets and sizes are measured in bytes. -They must be divided by 512 in order to obtain the block numbers that are to be used by `bsdlabel`. +They must be divided by 512 to obtain the block numbers that are to be used by `bsdlabel`. . Run this command for each device that participates in the root volume: + [source,shell] @@ -684,7 +700,7 @@ If this file system is to be mounted read-write later on, it is necessary to rem ==== Only Primary Bootstrap Loads If [.filename]#/boot/loader# fails to load, but the primary bootstrap still loads (visible by a single dash in the left column of the screen right after the boot process starts), an attempt can be made to interrupt the primary bootstrap by pressing kbd:[space]. -This will make the bootstrap stop in link:{handbook}#boot-boot1[stage two]. +This will make the bootstrap stop in extref:{handbook}[stage two, boot-boot1]. An attempt can be made here to boot off an alternate partition, like the partition containing the previous root file system that has been moved away from `a`. [[vinum-root-panic]] @@ -695,6 +711,6 @@ Unfortunately, [.filename]#vinum# accidentally leaves only 4 KB at the beginning However, the stage one and two bootstraps plus the bsdlabel require 8 KB. So if a [.filename]#vinum# partition was started at offset 0 within a slice or disk that was meant to be bootable, the [.filename]#vinum# setup will trash the bootstrap. -Similarly, if the above situation has been recovered, by booting from a "Fixit" media, and the bootstrap has been re-installed using `bsdlabel -B` as described in link:{handbook}#boot-boot1[stage two], the bootstrap will trash the [.filename]#vinum# header, and [.filename]#vinum# will no longer find its disk(s). +Similarly, if the above situation has been recovered, by booting from a "Fixit" media, and the bootstrap has been re-installed using `bsdlabel -B` as described in extref:{handbook}[stage two, boot-boot1], the bootstrap will trash the [.filename]#vinum# header, and [.filename]#vinum# will no longer find its disk(s). Though no actual [.filename]#vinum# configuration data or data in [.filename]#vinum# volumes will be trashed, and it would be possible to recover all the data by entering exactly the same [.filename]#vinum# configuration data again, the situation is hard to fix. -It is necessary to move the entire [.filename]#vinum# partition by at least 4 KB, in order to have the [.filename]#vinum# header and the system bootstrap no longer collide. +It is necessary to move the entire [.filename]#vinum# partition by at least 4 KB, to have the [.filename]#vinum# header and the system bootstrap no longer collide. |