---
title: Chapitre 22. Le gestionnaire de volume Vinum
part: Partie III. Administration Système
prev: books/handbook/filesystems
next: books/handbook/virtualization
showBookMenu: true
weight: 26
params:
  path: "/books/handbook/vinum/"
---

[[vinum-vinum]]
= Le gestionnaire de volume Vinum
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:sectnumoffset: 22
:partnums:
:source-highlighter: rouge
:experimental:
:images-path: books/handbook/vinum/

ifdef::env-beastie[]
ifdef::backend-html5[]
:imagesdir: ../../../../images/{images-path}
endif::[]
ifndef::book[]
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[]
toc::[]
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]

ifndef::env-beastie[]
toc::[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]

[[vinum-synopsis]]
== Synopsis

Peu importe les disques dont vous disposez, ils seront toujours limités:

* Ils pourront être trop petits.
* Ils pourront être trop lents.
* Ils pourront être peu fiables.

[[vinum-intro]]
== Les disques sont trop petits

_Vinum_ est un _gestionnaire de volume_, un pilote de disque virtuel qui permet de résoudre ces trois problèmes. Regardons-les plus en détails. De nombreuses solutions à ces problèmes ont été proposées et implémentées:

Les disques deviennent de plus en plus gros, mais tout comme les besoins en stockage. Vous vous apercevrez souvent que vous avez besoin d'un système de fichiers plus grand que les disques que vous avez à votre disposition. Bien évidemment, ce problème n'est plus aussi aigu qu'il l'était il y a de cela dix ans, mais il existe toujours. Certains systèmes l'ont résolu en créant un périphérique abstrait qui stocke ses données sur plusieurs disques.

== Les goulots d'étranglement d'accès aux données

Les systèmes modernes ont fréquemment besoin d'accéder aux données d'une manière hautement concourante. Par exemple, d'importants serveurs FTP ou HTTP peuvent supporter des milliers de sessions concourantes et avoir de multiple connexions à 100 Mbit/s vers le monde extérieur, et cela bien au-delà du taux de transfert soutenu de la plupart des disques.

Les disques actuels peuvent effectuer des transfert séquentiels de données jusqu'à une vitesse de 70 MO/s, mais ce chiffre a peu d'importance dans un environnement où plusieurs processus indépendants accèdent à un disque, où l'on pourra n'atteindre qu'une fraction de cette valeur. Dans de tels cas il est plus intéressant de voir le problème du point de vue du sous-système des disques: le paramètre important est la charge que provoque un transfert sur le sous-système, en d'autres termes le temps d'occupation du disque impliqué dans le transfert.

Dans n'importe quel transfert, le disque doit tout d'abord positionner les têtes de lecture, attendre le passage du premier secteur sous la tête de lecture, puis effectuer le transfert. Ces actions peuvent être considérées comme étant atomiques: cela n'a aucun sens de les interrompre.

[[vinum-latency]] Considérons un transfert typique d'environ 10 KO: la génération actuelle de disques hautes performances peuvent positionner leurs têtes en environ 3.5 ms. Les disques les plus véloces tournent à 15000 tr/minute, donc le temps de latence moyen de rotation (un demi-tour) est de 2 ms. A 70 MO/s, le transfert en lui-même prend environ 150 μs, presque rien comparé au temps de positionnement. Dans un tel cas, le taux de transfert effectif tombe à un peu plus de 1 MO/s et est clairement hautement dépendant de la taille du transfert.

La solution classique et évidente à ce goulot d'étranglement est "plus de cylindres": plutôt que d'utiliser un gros disque, on utilise plusieurs disques plus petits avec le même espace de stockage. Chaque disque est en mesure d'effectuer un transfert indépendamment des autres, aussi le taux de sortie augmente d'un facteur proche du nombre de disques utilisés.

L'amélioration du taux réel de sortie est, naturellement, inférieure au nombre de disques impliqués: bien que chaque disque soit capable de transférer en parallèle, il n'y a aucun moyen de s'assurer que les requêtes sont distribuées équitablement entre les disques. Inévitablement la charge d'un disque sera plus importante que celle d'un autre.

La répartition de la charge sur les disques dépend fortement de la manière dont les données sont partagées entre les disques. Dans la discussion suivant, il sera pratique de penser au stockage disque en tant qu'un grand nombre de secteurs qui sont adressables par l'intermédiaire d'un nombre, plutôt que comme les pages d'un livre. La méthode la plus évidente est de diviser le disque virtuel en groupes de secteurs consécutifs de taille égale aux disques physiques individuels et de les stocker de cette manière, plutôt que de les prendre comme un gros livre et de le déchirer en petites sections. Cette méthode est appelée _concaténation_ et a pour avantage que les disques n'ont pas besoin d'avoir de rapport spécifique au niveau de leur taille respective. Cela fonctionne bien quand l'accès au disque virtuel est réparti de façon identique sur son espace d'adressage. Quand l'accès est limité à une petite zone, l'amélioration est moins marquée. <<vinum-concat>> décrit la séquence dans laquelle les unités sont assignées dans une organisation par concaténation.

[[vinum-concat]]
.Organisation par concaténation
image::vinum-concat.png[]

Une organisation alternative est de diviser l'espace adressable en composants plus petits, de même taille et de les stocker séquentiellement sur différents périphériques. Par exemple, les 256 premiers secteurs peuvent être stockés sur le premier disque, les 256 secteurs suivants sur le disque suivant et ainsi de suite. Après avoir atteint le dernier disque, le processus se répète jusqu'à ce que les disques soient pleins. Cette organisation est appelée _striping_ (découpage en bande ou segmentation) ou RAID-0.

La segmentation exige légèrement plus d'effort pour localiser les données, et peut causer une charge additionnelle d'E/S quand un transfert est réparti sur de multiples disques, mais il peut également fournir une charge plus constante sur les disques. <<vinum-striped>> illustre l'ordre dans lequel les unités de stockage sont assignées dans une organisation segmentée.

[[vinum-striped]]
.Organisation segmentée
image::vinum-striped.png[]

== Intégrité des données

Le dernier problème avec les disques actuels est qu'ils ne sont pas fiables. Bien que la fiabilité des disques s'est énormément améliorée depuis quelques années, ils sont toujours le composant principal d'un serveur le plus susceptible de tomber en panne. Et quand cela arrive, les résultats peuvent être catastrophiques: remplacer un disque en panne et restaurer les données peut prendre plusieurs jours.

La méthode originelle d'approche de ce problème fut le mode _miroir_, en conservant deux copies des données sur un matériel différent. Depuis l'avènement de la technologie RAID, cette technique est également nommée RAID niveau 1 ou RAID-1. Toute opération d'écriture sur le volume écrit sur les deux unités; une lecture peut être acquittée par l'une ou l'autre, aussi si l'un des disque tombe en panne, les données sont toujours accessibles sur l'autre disque.

Le mode miroir présente deux problèmes:

* Le prix. Il demande au moins deux fois autant d'espace disque qu'une solution non-redondante.
* L'impact sur la performance. Les écritures doivent être effectuées sur les deux disques, elles prennent donc deux fois plus de bande passante que sur un volume sans miroir. Les lectures de souffrent pas de baisse de performance: elles semblent même plus rapides.

Une alternative est l'utilisation de la _parité_, implémentée sous les niveaux RAID 2, 3, 4 et 5. De ces niveaux RAID-5 est le plus intéressant. Comme implémenté dans Vinum, c'est une variante de l'organisation segmentée qui dédie un bloc de chaque segment à la parité des autres blocs. Comme implémenté dans Vinum, un volume RAID-5 est identique à un volume segmenté, sauf qu'il implémente RAID-5 en incluant un bloc de parité dans chaque unité. Comme l'exige RAID-5, l'emplacement de ce bloc de parité varie d'une unité à l'autre. Le nombre de blocs de données indique le nombre relatif de blocs.

[[vinum-raid5-org]]
.Organisation RAID-5
image::vinum-raid5-org.png[]

Comparé au mode miroir, RAID-5 a pour avantage de demander un espace de stockage significativement plus faible. L'accès en lecture est semblable à celui de l'organisation segmentée, mais l'accès en écriture est bien plus lent, approximativement 25% des performances en lecture. Si un disque tombe en panne, l'ensemble peut continuer à fonctionner dans un mode dégradé: une lecture sur un disque restant accessible se poursuit normalement, mais une lecture du disque perdu est recalculée à partir du bloc correspondant sur l'ensemble des disques restants.

[[vinum-objects]]
== Objets Vinum

Afin de résoudre ces problèmes, Vinum implémente une hiérarchie d'objets à quatre niveaux:

* L'objet le plus visible est le disque virtuel, appelé _volume_. Les volumes ont essentiellement les mêmes propriétés qu'un disque UNIX(TM), bien qu'il y ait quelques différences mineures. Ils n'ont aucune limitation de taille.
* Les volumes sont composés de _plexes_, chacune d'entre elles représente l'ensemble de l'espace d'adressable d'un volume. Ce niveau dans la hiérarchie permet ainsi la redondance. Pensez aux plexes comme différents disques dans un ensemble miroir, chacun contenant les mêmes données.
* Comme Vinum existe dans le système de stockage disque d'UNIX(TM), il serait possible d'utiliser les partitions UNIX(TM) pour construire des blocs pour des plexes à disques multiples, mais en fait cela ne serait pas suffisamment flexible: les disques UNIX(TM) ne peuvent avoir qu'un nombre limités de partitions. Au lieu de cela Vinum subdivise une simple partition UNIX(TM) (le _disque_) en zones contiguës appelées _sous-disques_, qui sont utilisés comme bloc pour construire les plexes.
* Les sous-disques résident sur le _disque_ Vinum, en fait les partitions UNIX(TM). Les disques Vinum peuvent contenir un nombre quelconque de sous-disque. A l'exception d'une petite zone au début du disque, qui est utilisée pour stocker les informations de configuration et d'état, l'intégralité du disque est disponible pour le stockage des données.

Les sections suivantes décrivent la façon dont ces objets fournissent les fonctionnalités requises pour Vinum.

=== Considérations sur la taille des volumes

Les plexes peuvent comprendre de multiple sous-disques répartis sur tous les disques dans la configuration Vinum. Par conséquent, la taille d'un disque ne limite pas la taille d'une plex, et donc d'un volume.

=== Stockage de données redondant

Vinum implémente le mode miroir en attachant de multiples plexes à un volume. Un volume peut contenir entre une et huit plexes.

Bien qu'une plex représente les données complètes d'un volume, il est possible que des parties de la représentation soient physiquement manquantes, soit en raison de la mise en place (en définissant un sous-disque comme ne faisant pas partie de la plex) ou par accident (en raison de la panne d'un disque). Tant qu'au moins une plex peut fournir les données de l'intégralité de la plage d'adresse d'un volume, le volume est totalement fonctionnel.

=== Problèmes de performance

Vinum implémente la concaténation et la segmentation au niveau de la plex:

* Une _plex concaténée_ utilise alternativement l'espace d'adresse de chaque sous-disque.
* Une _plex segmentée_ segmente les données sur chaque sous-disque. Les sous-disques doivent avoir la même taille, et il doit y avoir au moins deux sous-disques pour distinguer la plex d'une plex concaténée.

=== Quelle organisation de plex?

La version de Vinum fournie avec FreeBSD {rel120-current} implémente deux type de plexes:

* Les plexes concaténées sont les plus flexibles: elles peuvent contenir un nombre quelconque de de sous-disques, et les sous-disques peuvent être de taille différentes. La plex peut être étendue en ajoutant des sous-disques supplémentaires. Elles demandent moins de temps CPU que les plexes segmentées, bien que la différence en charge CPU ne soit pas mesurable. D'autre part, elles sont plus susceptibles d'échauffement, là où un disque est très actif et les autres sont au repos.
* Le plus grand avantage des plexes segmentées (RAID-0) est qu'elles réduisent les problèmes d'échauffement: en choisissant tailles de segments optimales (environ 256 KO), vous pouvez également réduire la charge des disques. Les inconvénients de cette approche sont un code (infimement) plus complexe et des restrictions sur les sous-disques: ils doivent être de la même taille, et agrandir une plex en ajoutant de nouveaux sous-disques est si complexe que Vinum ne l'implémente pas actuellement. Vinum impose une restriction triviale supplémentaire: une plex segmentée doit avoir au moins deux sous-disques, puisque sinon elle ne serait distinguable d'une plex concaténée.

<<vinum-comparison>> résume les avantages et inconvénients de chaque type d'organisation de plex.

[[vinum-comparison]]
.Organisations de plex Vinum
[cols="1,1,1,1,1", options="header"]
|===
| Type de plex
| Nombre minimal de sous-disques
| Possibilité d'ajout de sous-disques
| Doivent être de même taille
| Application

|concaténée
|1
|oui
|non
|Stockage de grandes quantités de données avec le maximum de flexibilité en terme de placement et des performances modérées

|segmentée
|2
|non
|oui
|Haute performance combinée avec un accès hautement concourant
|===

[[vinum-examples]]
== Quelques exemples

Vinum maintient une _base de données de configuration_ qui décrit les objets connus pour un système individuel. Initialement, l'utilisateur créé la base de données de configuration à partir d'un ou plusieurs fichiers de configuration avec l'aide de l'utilitaire man:vinum[8]. Vinum conserve une copie de sa base de données de configuration sur chaque tranche (que Vinum nomme _device_) sous son contrôle. Cette base données est mise à jour à chaque changement d'état, aussi un redémarrage reconstitue exactement l'état de chaque objet Vinum.

=== Le fichier de configuration

Le fichier de configuration décrit les objets Vinum. La définition d'un simple volume pourrait être:

[.programlisting]
....

    drive a device /dev/da3h
    volume myvol
      plex org concat
        sd length 512m drive a
....

Ce fichier décrit quatre objets Vinum:

* La ligne _drive_ une partition disque (_drive_) et son emplacement relatif par rapport au matériel sous-jacent. On lui donne le nom symbolique _a_. Cette séparation entre le nom symbolique et le nom du périphérique permet aux disques d'être déplacés d'un emplacement à un autre sans confusion possible.
* La ligne _volume_ décrit un volume. Le seul attribut nécessaire est le nom, dans notre cas _myvol_.
* La ligne _plex_ définit une plex. Le seul paramètre requit est l'organisation, dans ce cas _concat_. Aucun nom n'est nécessaire: le système génère automatiquement un nom à partir du nom de volume en ajoutant le suffixe _.px_, où _x_ est le nombre de plexes dans le volume. Donc cette plex sera appelée __myvol.p0__.
* La ligne _sd_ décrit un sous-disque. Les spécifications minimales sont le nom du disque sur lequel le stocker et la taille du sous-disque. Comme pour les plexes, aucun nom n'est nécessaire: le système assignera automatiquement des noms dérivés du nom de la plex en ajoutant le suffixe _.sx_, où _x_ est le nombre de sous-disques dans la plex. Donc Vinum donnera le nom __myvol.p0.s0__ à ce sous-disque.

Après avoir traité ce fichier man:vinum[8] affiche ce qui suit:

[.programlisting]
....

      #  vinum - create config1
      Configuration summary
      Drives:         1 (4 configured)
      Volumes:        1 (4 configured)
      Plexes:         1 (8 configured)
      Subdisks:       1 (16 configured)

	D a                     State: up       Device /dev/da3h        Avail: 2061/2573 MB (80%)

	V myvol                 State: up       Plexes:       1 Size:        512 MB

	P myvol.p0            C State: up       Subdisks:     1 Size:        512 MB

	S myvol.p0.s0           State: up       PO:        0  B Size:        512 MB
....

Cette sortie affiche une brève liste du format man:vinum[8]. Elle est représentée graphiquement dans <<vinum-simple-vol>>.

[[vinum-simple-vol]]
.Un simple volume Vinum
image::vinum-simple-vol.png[]

Cette figure, et celles qui suivent, représentent un volume qui contient les plexes, qui à leur tour contiennent les sous-disques. Dans cet exemple trivial, le volume contient une plex, et la plex contient un sous-disque.

Ce volume particulier ne présente aucun avantage spécifique par rapport à une partition de disque conventionnelle. Il contient une seule plex, donc il n'est pas redondant. La plex contient un seul sous-disque, il n'y a donc pas de différence dans l'organisation du stockage des données par rapport à une partition de disque conventionnelle. Les sections suivantes présenteront diverses méthodes de configuration plus intéressantes.

=== Robustesse accrue: le mode miroir

La robustesse d'un volume peut être augmentée par le mode miroir. Quand on implémente un volume en mode miroir, il est important de s'assurer que les sous-disques de chaque plex sont sur des disques différents, de sorte qu'une panne disque ne mette hors service les deux plexes. La configuration suivante place en mode miroir un volume:

[.programlisting]
....

	drive b device /dev/da4h
	volume mirror
      plex org concat
        sd length 512m drive a
	  plex org concat
	    sd length 512m drive b
....

Dans cet exemple, il n'était pas nécessaire de spécifier une définition de disque _a_ à nouveau, puisque Vinum garde trace de tous les objets dans sa base de données de configuration. Après le traitement de cette définition, la configuration ressemble à:

[.programlisting]
....

	Drives:         2 (4 configured)
	Volumes:        2 (4 configured)
	Plexes:         3 (8 configured)
	Subdisks:       3 (16 configured)

	D a                     State: up       Device /dev/da3h        Avail: 1549/2573 MB (60%)
	D b                     State: up       Device /dev/da4h        Avail: 2061/2573 MB (80%)

    V myvol                 State: up       Plexes:       1 Size:        512 MB
    V mirror                State: up       Plexes:       2 Size:        512 MB

    P myvol.p0            C State: up       Subdisks:     1 Size:        512 MB
    P mirror.p0           C State: up       Subdisks:     1 Size:        512 MB
    P mirror.p1           C State: initializing     Subdisks:     1 Size:        512 MB

    S myvol.p0.s0           State: up       PO:        0  B Size:        512 MB
	S mirror.p0.s0          State: up       PO:        0  B Size:        512 MB
	S mirror.p1.s0          State: empty    PO:        0  B Size:        512 MB
....

<<vinum-mirrored-vol>> présente la structure sous forme graphique.

[[vinum-mirrored-vol]]
.Un volume Vinum en mode miroir
image::vinum-mirrored-vol.png[]

Dans cet exemple, chaque plex contient un espace d'adressage de 512 MO. Comme dans l'exemple précédent, chaque plex contient seulement un seul sous-disque.

=== Optimiser les performances

Le volume en mode miroir de l'exemple précédent est plus résistant aux pannes qu'un volume sans miroir, mais ses performances sont moindres: chaque écriture sur le volume demande d'écrire sur les deux disques, utilisant alors une plus grande proportion de la bande passante disque totale. Des considérations sur les performances demandent une approche différente: à la place d'un miroir, les données sont segmentées sur autant de disques que possible. La configuration suivante montre un volume avec une plex segmentée sur quatre disques:

[.programlisting]
....

	drive c device /dev/da5h
	drive d device /dev/da6h
	volume stripe
	plex org striped 512k
	  sd length 128m drive a
	  sd length 128m drive b
	  sd length 128m drive c
	  sd length 128m drive d
....

Comme précédemment, il n'est pas nécessaire de définir les disques qui sont déjà connus de Vinum. Après traitement de cette définition, la configuration ressemble à:

[.programlisting]
....

	Drives:         4 (4 configured)
	Volumes:        3 (4 configured)
	Plexes:         4 (8 configured)
	Subdisks:       7 (16 configured)

    D a                     State: up       Device /dev/da3h        Avail: 1421/2573 MB (55%)
    D b                     State: up       Device /dev/da4h        Avail: 1933/2573 MB (75%)
    D c                     State: up       Device /dev/da5h        Avail: 2445/2573 MB (95%)
    D d                     State: up       Device /dev/da6h        Avail: 2445/2573 MB (95%)

    V myvol                 State: up       Plexes:       1 Size:        512 MB
    V mirror                State: up       Plexes:       2 Size:        512 MB
    V striped               State: up       Plexes:       1 Size:        512 MB

    P myvol.p0            C State: up       Subdisks:     1 Size:        512 MB
    P mirror.p0           C State: up       Subdisks:     1 Size:        512 MB
    P mirror.p1           C State: initializing     Subdisks:     1 Size:        512 MB
    P striped.p1            State: up       Subdisks:     1 Size:        512 MB

    S myvol.p0.s0           State: up       PO:        0  B Size:        512 MB
    S mirror.p0.s0          State: up       PO:        0  B Size:        512 MB
    S mirror.p1.s0          State: empty    PO:        0  B Size:        512 MB
    S striped.p0.s0         State: up       PO:        0  B Size:        128 MB
    S striped.p0.s1         State: up       PO:      512 kB Size:        128 MB
    S striped.p0.s2         State: up       PO:     1024 kB Size:        128 MB
    S striped.p0.s3         State: up       PO:     1536 kB Size:        128 MB
....

[[vinum-striped-vol]]
.Un volume Vinum segmenté
image::vinum-striped-vol.png[]

Ce volume est représenté sur <<vinum-striped-vol>>. La couleur des segments indique leur position dans l'espace d'adresses de la plex: le segment le plus clair vient en premier, le plus sombre en dernier.

=== Robustesse et performances

[[vinum-resilience]]Avec suffisamment de matériel, il est possible de créer des volumes qui présenteront une robustesse et des performances accrues comparés aux partitions UNIX(TM) standards. Un fichier de configuration pourrait être:

[.programlisting]
....

	volume raid10
      plex org striped 512k
        sd length 102480k drive a
        sd length 102480k drive b
        sd length 102480k drive c
        sd length 102480k drive d
        sd length 102480k drive e
      plex org striped 512k
        sd length 102480k drive c
        sd length 102480k drive d
        sd length 102480k drive e
        sd length 102480k drive a
        sd length 102480k drive b
....

Les sous-disques de la seconde plex sont décalés de deux disques par rapport à ceux de la première plex: cela aide à s'assurer que les écritures ne vont pas sur les même sous-disques même si un transfert s'effectue sur les deux disques.

<<vinum-raid10-vol>> représente la structure de ce volume.

[[vinum-raid10-vol]]
.Un volume Vinum en mode miroir segmenté
image::vinum-raid10-vol.png[]

== Appellation des objets

Comme décrit précédemment, Vinum assigne des noms par défaut aux plexes et aux sous-disques, bien qu'ils peuvent être imposés. Ne pas conserver les noms par défaut n'est pas recommandé: une expérience avec le gestionnaire de volume VERITAS, qui autorise les noms arbitraires pour les objets, a montré que cette flexibilité n'apporte pas d'avantage significatif, et peut être à l'origine de confusion.

Les noms pourront contenir tout caractère non vide, mais il est recommandé de se cantonner aux lettres, chiffres ou le caractère souligné. Les noms de volumes, plexes et sous-disques peuvent contenir jusqu'à 64 caractères, et le nom des disques 32 caractères.

On assigne à chaque objet Vinum un fichier spécial de périphérique dans la hiérarchie [.filename]#/dev/vinum#. La configuration présentée plus haut aurait fait à Vinum créer les fichiers spéciaux de périphérique suivants:

* Les périphériques de contrôle [.filename]#/dev/vinum/control# et [.filename]#/dev/vinum/controld#, qui sont respectivement utilisés par man:vinum[8]et le "daemon" Vinum.
* Les entrées des périphériques en mode bloc et caractères par chaque volume. Ce sont les périphériques principaux utilisés par Vinum. Les noms de périphériques en mode bloc sont le nom du volume, alors que les noms de périphériques en mode caractère suivent la tradition BSD de faire précéder le nom de la lettre _r_. Donc la configuration précédent inclurait les périphériques en mode bloc [.filename]#/dev/vinum/myvol#, [.filename]#/dev/vinum/mirror#, [.filename]#/dev/vinum/striped#, [.filename]#/dev/vinum/raid5# et [.filename]#/dev/vinum/raid10#, et les périphériques en mode caractères [.filename]#/dev/vinum/rmyvol#, [.filename]#/dev/vinum/rmirror#, [.filename]#/dev/vinum/rstriped#, [.filename]#/dev/vinum/rraid5# et [.filename]#/dev/vinum/rraid10#. Un problème évident apparaît ici: il est possible d'avoir deux volumes appelés _r_ et _rr_, mais il y aurait un conflit lors de la création du fichier spécial de périphérique [.filename]#/dev/vinum/rr#: c'est le périphérique en mode caractère du volume _r_ ou le périphérique en mode bloc du volume _rr_? Actuellement Vinum ne résout pas ce conflit: le premier volume défini obtiendra le nom.
* Un répertoire [.filename]#/dev/vinum/drive# avec des entrées pour chaque disque. Ces entrées sont en fait des liens symboliques vers les fichiers spéciaux de périphérique de disque correspondants.
* Un répertoire [.filename]#/dev/vinum/volume# avec des entrées pour chaque volume. Il contient des sous-répertoires pour chaque plex, qui à leur tour contiennent des sous-répertoires pour leurs sous-disques.
* Les répertoires [.filename]#/dev/vinum/plex#, [.filename]#/dev/vinum/sd#, et [.filename]#/dev/vinum/rsd#, qui contiennent les fichiers spéciaux de périphérique en mode bloc pour chaque plex et les fichiers spéciaux de périphérique en mode bloc et caractère pour chaque sous-disque.

Par exemple, considérons le fichier de configuration suivant:

[.programlisting]
....

	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
....

Après traitement de ce fichier, man:vinum[8] crée la structure suivante dans [.filename]#/dev/vinum#:

[.programlisting]
....

	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
....

Bien qu'il soit recommandé de ne pas donner de nom spécifique aux plexes et sous-disques, les disques Vinum doivent avoir un nom. Cela rend possible de déplacer un disque à un emplacement différent et qu'il soit toujours reconnu automatiquement. Les noms de disques peuvent avoir jusqu'à 32 caractères.

=== Création de systèmes de fichiers

Les volumes apparaissent pour le système comme des disques, avec une seule exception. Contrairement aux disques UNIX(TM), Vinum ne partitionne pas les volumes, qui ne contiennent donc pas de table de partitionnement. Cela a demandé de modifier certains utilitaires disque, en particulier man:newfs[8], qui auparavant tentait d'interpréter la dernière lettre du nom de volume Vinum comme un identifiant de partition. Par exemple, un disque peut avoir un nom comme [.filename]#/dev/ad0a#$ ou [.filename]#/dev/da2h#. Ces noms représentent respectivement la première partition ([.filename]#a#) sur le premier (0) disque IDE ([.filename]#ad#) la la huitième partition ([.filename]#h#) sur le troisième (2) disque SCSI ([.filename]#da#). En revanche, un volume Vinum pourra être appelé [.filename]#/dev/vinum/concat#, un nom qui n'a pas de relation avec un nom de partition.

Normalement, man:newfs[8] interprète le nom du disque et se plaint s'il ne peut le comprendre. Par exemple:

[source,shell]
....
# newfs /dev/vinum/concat
newfs: /dev/vinum/concat: can't figure out file system partition
....

Afin de créer un système de fichiers sur ce volume, utilisez l'option `-v` de man:newfs[8]:

[source,shell]
....
# newfs -v /dev/vinum/concat
....

[[vinum-config]]
== Configuration de Vinum

Le noyau [.filename]#GENERIC# ne contient pas le support Vinum. Il est possible de compiler un noyau spécial qui inclut vinum, mais cela n'est pas recommandé. La méthode standard de lancement de Vinum est d'utiliser un module du noyau (kld). Vous n'avez même pas besoin d'utiliser man:kldload[8] pour Vinum: quand vous lancez man:vinum[8], il contrôle si le module a été chargé ou non, si ce n'est pas le cas, il le charge automatiquement.

=== Démarrage

Vinum stocke l'information de configuration sur les tranches des disques sous la même forme que dans les fichiers de configuration. En lisant à partir de la base de données de configuration, Vinum reconnaît un certain nombre de mots clés qui ne sont pas autorisés dans les fichiers de configuration. Par exemple, une configuration de disque pourrait contenir le texte suivant:

[.programlisting]
....
volume myvol state up
volume bigraid state down
plex name myvol.p0 state up org concat vol myvol
plex name myvol.p1 state up org concat vol myvol
plex name myvol.p2 state init org striped 512b vol myvol
plex name bigraid.p0 state initializing org raid5 512b vol bigraid
sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b
sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b
sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b
sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b
sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b
sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b
sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b
sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b
sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b
sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b
sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b
sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b
sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b
....

Ici les différences évidentes sont la présence d'une information explicite sur l'emplacement et le nom (les deux sont également autorisés, mais leur utilisation est déconseillée à l'utilisateur) et de l'information sur les états (qui ne sont pas disponibles à l'utilisateur). Vinum ne stocke pas d'informations au sujet des disques dans la configuration: il localise les disques en recherchant les disques configurés pour les partitions dans le label Vinum. Cela permet à Vinum d'identifier correctement les disques même s'ils ont un identifiant de disque UNIX(TM) différent.

==== Démarrage automatique

Afin de lancer automatiquement Vinum au démarrage du système, assurez-vous d'avoir la ligne suivante dans votre fichier [.filename]#/etc/rc.conf#:

[.programlisting]
....
start_vinum="YES"		# set to YES to start vinum
....

Si vous n'avez pas de fichier [.filename]#/etc/rc.conf#, créez en un avec cette ligne. Cela provoquera le chargement du module Vinum au démarrage du système, et le lancement de tout objet mentionné dans la configuration. Cela est fait avant de monter les systèmes de fichiers, il est donc possible d'utiliser automatiquement man:fsck[8] sur des systèmes de fichiers puis de les monter sur des volumes Vinum.

quand vous démarrez avec la commande `vinum start`, Vinum lit la base de données de configuration à partir d'un des disques Vinum. Dans des circonstances normales, chaque disque contient une copie identique de la base de données de configuration, il importe donc peu quel disque est lu. Après un crash, Vinum doit déterminer quel disque a été mis à jour le plus récemment et lire la configuration à partir de ce disque. Il met ensuite à jour la configuration si nécessaire à partir de disques progressivement de plus en plus anciens.
