<!--
	The Vinum Volume Manager
	Par Greg Lehey (grog at lemis dot com)

	Ajout&eacute; au Manuel par Hiten Pandya <hiten@uk.FreeBSD.org>
	et Tom Rhodes <trhodes@FreeBSD.org>

	The FreeBSD Documentation Project
	The FreeBSD French Documentation Project

	$FreeBSD$
	$Id: chapter.sgml,v 1.3 2002-11-17 11:00:51 blackend Exp $
	Original revision: 1.13
-->

<chapter id="vinum-vinum">
  <title>Le gestionnaire de volume Vinum</title>
  &trans.a.fonvieille;

  <sect1 id="vinum-synopsis">
    <title>Synopsis</title>

    <para>Peu importe les disques dont vous disposez, ils seront
      toujours limit&eacute;s:</para>
      <itemizedlist>
	<listitem>
	  <para>Ils pourront &ecirc;tre trop petits.</para>
	</listitem>

	<listitem>
	  <para>Ils pourront &ecirc;tre trop lents.</para>
	</listitem>

	<listitem>
	  <para>Ils pourront &ecirc;tre peu fiables.</para>
	</listitem>
      </itemizedlist>
  </sect1>

  <sect1 id="vinum-intro">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Greg</firstname>
	  <surname>Lehey</surname>
	  <contrib>Ecrit &agrave; l'origine par </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Les disques sont trop petits</title>

    <indexterm><primary>Vinum</primary></indexterm>
    <indexterm><primary>Volume</primary>
    <secondary>Gestionnaire</secondary></indexterm>

    <para><emphasis>Vinum</emphasis> est un
      <emphasis>gestionnaire de volume</emphasis>, un pilote de disque
      virtuel qui permet de r&eacute;soudre ces trois probl&egrave;mes.
      Regardons-les plus en d&eacute;tails.  De nombreuses solutions &agrave;
      ces probl&egrave;mes ont &eacute;t&eacute; propos&eacute;es et
      impl&eacute;ment&eacute;es:</para>

    <para>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&egrave;me de fichiers plus grand que les disques
      que vous avez &agrave; votre disposition.  Bien &eacute;videmment,
      ce probl&egrave;me n'est plus aussi aigu qu'il l'&eacute;tait il y
      a de cela dix ans, mais il existe toujours.  Certains syst&egrave;mes
      l'ont r&eacute;solu en cr&eacute;ant un p&eacute;riph&eacute;rique
      abstrait qui stocke ses donn&eacute;es sur plusieurs disques.</para>
  </sect1>

  <sect1>
    <title>Les goulots d'&eacute;tranglement d'acc&egrave;s aux
      donn&eacute;es</title>
    <para>Les syst&egrave;mes modernes ont fr&eacute;quemment besoin
      d'acc&eacute;der aux donn&eacute;es d'une mani&egrave;re hautement
      concourante.  Par exemple, d'importants serveurs FTP ou HTTP
      peuvent supporter des milliers de sessions concourantes et avoir
      de multiple connexions &agrave; 100&nbsp;Mbit/s vers le monde
      ext&eacute;rieur, et
      cela bien au-del&agrave; du taux de transfert soutenu de la plupart des
      disques.</para>

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

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

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

    <para>La solution classique et &eacute;vidente &agrave; ce goulot
      d'&eacute;tranglement est &ldquo;plus de cylindres&rdquo;:
      plut&ocirc;t que d'utiliser un gros disque, on utilise plusieurs
      disques plus petits avec le m&ecirc;me espace de stockage.
      Chaque disque est en mesure d'effectuer un transfert
      ind&eacute;pendamment des autres, aussi le taux de sortie augmente d'un
      facteur proche du nombre de disques utilis&eacute;s.</para>

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

    <indexterm>
      <primary>concat&eacute;nation</primary>
      <secondary>Vinum</secondary>
    </indexterm>
    <indexterm>
      <primary>Vinum</primary>
      <secondary>concat&eacute;nation</secondary>
    </indexterm>

    <para>La r&eacute;partition de la charge sur les disques d&eacute;pend
      fortement de la mani&egrave;re dont les donn&eacute;es sont
      partag&eacute;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&eacute;diaire d'un
      nombre, plut&ocirc;t que comme les pages d'un livre.  La m&eacute;thode
      la plus &eacute;vidente est de diviser le disque virtuel en groupes de
      secteurs cons&eacute;cutifs de taille &eacute;gale aux disques physiques
      individuels et de les stocker de cette mani&egrave;re, plut&ocirc;t que de
      les prendre comme un gros livre et de le d&eacute;chirer en
      petites sections.  Cette m&eacute;thode est appel&eacute;e
      <emphasis>concat&eacute;nation</emphasis> et a pour avantage que
      les disques n'ont pas besoin d'avoir de rapport sp&eacute;cifique au
      niveau de leur taille respective.  Cela fonctionne bien quand
      l'acc&egrave;s au disque virtuel est r&eacute;parti de fa&ccedil;on
      identique sur son espace d'adressage.  Quand l'acc&egrave;s est
      limit&eacute; &agrave; une petite
      zone, l'am&eacute;lioration est moins marqu&eacute;e.  <xref
      linkend="vinum-concat"> d&eacute;crit la s&eacute;quence dans laquelle les
      unit&eacute;s sont assign&eacute;es dans une organisation par
      concat&eacute;nation.</para>

    <para>
      <figure id="vinum-concat">
	<title>Organisation par concat&eacute;nation</title>
	<graphic fileref="vinum/vinum-concat">
      </figure>
    </para>

    <indexterm>
      <primary>striping</primary>
      <secondary>Vinum</secondary>
    </indexterm>
    <indexterm>
      <primary>Vinum</primary>
      <secondary>striping</secondary>
    </indexterm>

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

    <footnote>
      <indexterm>
	<primary>RAID</primary>
      </indexterm>
      <indexterm>
	<primary>Redundant</primary>
	<secondary>Array of Inexpensive Disks</secondary>
      </indexterm>

      <para><acronym>RAID</acronym> signifie <emphasis>Redundant Array of
	Inexpensive Disks</emphasis> (r&eacute;seau redondant de disques
	bons march&eacute;s) et offre diverses am&eacute;liorations de la
	tol&eacute;rance aux pannes, bien que le dernier terme soit
	l&eacute;g&egrave;rement
	trompeur: il ne fournit pas de redondance.</para>
    </footnote>.

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

    <para>
      <figure id="vinum-striped">
        <title>Organisation segment&eacute;e</title>
	<graphic fileref="vinum/vinum-striped">
      </figure>
    </para>
  </sect1>

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

      <indexterm>
	<primary>mode miroir</primary>
	<secondary>Vinum</secondary>
      </indexterm>
      <indexterm>
	<primary>Vinum</primary>
	<secondary>mode miroir</secondary>
      </indexterm>
      <indexterm>
	<primary>RAID</primary>
	<secondary>niveau 1</secondary>
      </indexterm>
      <indexterm>
	<primary>RAID-1</primary>
      </indexterm>

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

      <para>Le mode miroir pr&eacute;sente deux probl&egrave;mes:</para>

	<itemizedlist>
	  <listitem>
	    <para>Le prix.  Il demande au moins deux fois autant
	      d'espace disque qu'une solution non-redondante.</para>
	  </listitem>

	  <listitem>
	    <para>L'impact sur la performance.  Les &eacute;critures doivent
	      &ecirc;tre effectu&eacute;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&ecirc;me plus rapides.</para>
	  </listitem>
	</itemizedlist>

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

      <para>
	<figure id="vinum-raid5-org">
	  <title>Organisation RAID-5</title>
	  <graphic fileref="vinum/vinum-raid5-org">
	</figure>
      </para>

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

  <sect1 id="vinum-objects">
    <title>Objets Vinum</title>
      <para>Afin de r&eacute;soudre ces probl&egrave;mes,
	Vinum impl&eacute;mente une hi&eacute;rarchie d'objets &agrave; quatre
	niveaux:</para>

      <itemizedlist>
	<listitem>
	  <para>L'objet le plus visible est le disque virtuel,
	    appel&eacute; <emphasis>volume</emphasis>.  Les volumes ont
	    essentiellement les m&ecirc;mes propri&eacute;t&eacute;s qu'un
	    disque UNIX&trade;, bien qu'il y ait quelques diff&eacute;rences
	    mineures.  Ils n'ont aucune limitation de taille.</para>
	</listitem>

	<listitem>
	  <para>Les volumes sont compos&eacute;s de
	    <emphasis>plexes</emphasis>, chacune d'entre elles
	    repr&eacute;sente l'ensemble de l'espace d'adressable d'un
	    volume.  Ce niveau dans la hi&eacute;rarchie permet ainsi la
	    redondance.  Pensez aux plexes comme diff&eacute;rents disques
	    dans un ensemble miroir, chacun contenant les m&ecirc;mes
	    donn&eacute;es.</para>
	</listitem>

	<listitem>
	  <para>Comme Vinum existe dans le syst&egrave;me de stockage disque
	    d'UNIX&trade;, il serait possible d'utiliser les
	    partitions UNIX&trade; pour construire des blocs pour des
	    plexes &agrave; disques multiples, mais en fait cela ne serait
	    pas suffisamment flexible: les disques UNIX&trade; ne
	    peuvent avoir qu'un nombre limit&eacute;s de partitions.
	    Au lieu de cela Vinum subdivise une simple partition
	    UNIX&trade; (le <emphasis>disque</emphasis>) en zones
	    contig&uuml;es appel&eacute;es <emphasis>sous-disques</emphasis>,
	    qui sont utilis&eacute;s comme bloc pour construire les
	    plexes.</para>
	</listitem>

	<listitem>
	  <para>Les sous-disques r&eacute;sident sur le
	    <emphasis>disque</emphasis> Vinum, en fait les partitions
	    UNIX&trade;.  Les disques Vinum peuvent contenir un nombre
	    quelconque de sous-disque.  A l'exception d'une petite
	    zone au d&eacute;but du disque, qui est utilis&eacute;e pour stocker
	    les informations de configuration et d'&eacute;tat,
	    l'int&eacute;gralit&eacute;
	    du disque est disponible pour le stockage des
	    donn&eacute;es.</para>
	</listitem>
      </itemizedlist>

      <para>Les sections suivantes d&eacute;crivent la fa&ccedil;on dont
	ces objets fournissent les fonctionnalit&eacute;s requises pour
	Vinum.</para>

    <sect2>
      <title>Consid&eacute;rations sur la taille des volumes</title>

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

    <sect2>
      <title>Stockage de donn&eacute;es redondant</title>
      <para>Vinum impl&eacute;mente le mode miroir en attachant de multiples
	plexes &agrave; un volume.  Un volume peut contenir entre une et huit
	plexes.</para>

      <para>Bien qu'une plex repr&eacute;sente les donn&eacute;es
	compl&egrave;tes d'un volume, il est possible que des parties de la
	repr&eacute;sentation soient physiquement manquantes, soit en raison
	de la mise en place (en d&eacute;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&eacute;es de l'int&eacute;gralit&eacute; de la plage d'adresse
	d'un volume, le volume est totalement fonctionnel.</para>
    </sect2>

    <sect2>
      <title>Probl&egrave;mes de performance</title>
      <para>Vinum impl&eacute;mente la concat&eacute;nation et la
	segmentation au niveau de la plex:</para>

      <itemizedlist>
	<listitem>
	  <para>Une <emphasis>plex concat&eacute;n&eacute;e</emphasis>
	    utilise alternativement l'espace d'adresse de chaque
	    sous-disque.</para>
	</listitem>

	<listitem>
	  <para>Une <emphasis>plex segment&eacute;e</emphasis> segmente les
	    donn&eacute;es sur chaque sous-disque.  Les sous-disques doivent
	    avoir la m&ecirc;me taille, et il doit y avoir au moins deux
	    sous-disques pour distinguer la plex d'une plex
	    concat&eacute;n&eacute;e.</para>
	</listitem>
      </itemizedlist>
    </sect2>

    <sect2>
      <title>Quelle organisation de plex?</title>
      <para>La version de Vinum fournie avec FreeBSD &rel.current;
	impl&eacute;mente deux type de plexes:</para>

      <itemizedlist>
	<listitem>
	  <para>Les plexes concat&eacute;n&eacute;es sont les plus
	    flexibles: elles peuvent contenir un nombre quelconque de
	    de sous-disques, et les sous-disques peuvent &ecirc;tre de
	    taille diff&eacute;rentes.  La plex peut &ecirc;tre &eacute;tendue
	    en ajoutant des sous-disques suppl&eacute;mentaires.  Elles
	    demandent moins de temps <acronym>CPU</acronym> que les
	    plexes segment&eacute;es, bien que la diff&eacute;rence en charge
	    <acronym>CPU</acronym> ne soit pas mesurable.  D'autre
	    part, elles sont plus susceptibles d'&eacute;chauffement,
	    l&agrave; o&ugrave; un disque est tr&egrave;s actif et les autres
	    sont au repos.</para>
        </listitem>

	<listitem>
	  <para>Le plus grand avantage des plexes segment&eacute;es
	    (<acronym>RAID-0</acronym>) est qu'elles r&eacute;duisent
	    les probl&egrave;mes d'&eacute;chauffement: en choisissant tailles
	    de segments optimales (environ 256&nbsp;KO), vous pouvez
	    &eacute;galement r&eacute;duire la charge des disques.  Les
	    inconv&eacute;nients de cette approche sont un code (infimement)
	    plus complexe et des restrictions sur les sous-disques:
	    ils doivent &ecirc;tre de la m&ecirc;me taille, et agrandir une plex
	    en ajoutant de nouveaux sous-disques est si complexe que
	    Vinum ne l'impl&eacute;mente pas actuellement.  Vinum
	    impose une restriction triviale suppl&eacute;mentaire: une plex
	    segment&eacute;e doit avoir au moins deux sous-disques, puisque
	    sinon elle ne serait distinguable d'une plex
	    concat&eacute;n&eacute;e.</para>
	</listitem>
      </itemizedlist>

      <para><xref linkend="vinum-comparison"> r&eacute;sume les avantages et
	inconv&eacute;nients de chaque type d'organisation de plex.</para>

      <table id="vinum-comparison">
	<title>Organisations de plex Vinum</title>
	<tgroup cols="5">
	  <thead>
	    <row>
	      <entry>Type de plex</entry>
	  	<entry>Nombre minimal de sous-disques</entry>
	  	<entry>Possibilit&eacute; d'ajout de sous-disques</entry>
	  	<entry>Doivent &ecirc;tre de m&ecirc;me taille</entry>
	  	<entry>Application</entry>
	    </row>
	  </thead>

	  <tbody>
	    <row>
	      <entry>concat&eacute;n&eacute;e</entry>
	      <entry>1</entry>
	      <entry>oui</entry>
	      <entry>non</entry>
	      <entry>Stockage de grandes quantit&eacute;s de donn&eacute;es
		avec le maximum de flexibilit&eacute; en terme de placement
		et des performances mod&eacute;r&eacute;es</entry>
	    </row>

	    <row>
	      <entry>segment&eacute;e</entry>
	      <entry>2</entry>
	      <entry>non</entry>
	      <entry>oui</entry>
	      <entry>Haute performance combin&eacute;e avec un acc&egrave;s
		hautement concourant</entry>
	    </row>
	  </tbody>
	</tgroup>
      </table>
    </sect2>
  </sect1>

  <sect1 id="vinum-examples">
    <title>Quelques exemples</title>
    <para>Vinum maintient une <emphasis>base de donn&eacute;es de
      configuration</emphasis> qui d&eacute;crit les objets connus pour un
      syst&egrave;me individuel.  Initialement, l'utilisateur cr&eacute;&eacute;
      la base de donn&eacute;es de configuration &agrave; 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&eacute;es
      de configuration sur chaque tranche (que Vinum nomme
      <emphasis>device</emphasis>) sous son contr&ocirc;le.  Cette
      base donn&eacute;es est mise &agrave; jour &agrave; chaque changement
      d'&eacute;tat, aussi un red&eacute;marrage reconstitue exactement
      l'&eacute;tat de chaque objet Vinum.</para>

    <sect2>
      <title>Le fichier de configuration</title>
      <para>Le fichier de configuration d&eacute;crit les objets Vinum.
	La d&eacute;finition d'un simple volume pourrait &ecirc;tre:</para>

      <programlisting>
    drive a device /dev/da3h
    volume myvol
      plex org concat
        sd length 512m drive a</programlisting>

      <para>Ce fichier d&eacute;crit quatre objets Vinum:</para>

      <itemizedlist>
	<listitem>
	  <para>La ligne <emphasis>drive</emphasis> une partition
	    disque (<emphasis>drive</emphasis>) et son emplacement
	    relatif par rapport au mat&eacute;riel sous-jacent.  On lui donne
	    le nom symbolique <emphasis>a</emphasis>.  Cette
	    s&eacute;paration entre le nom symbolique et le nom du
	    p&eacute;riph&eacute;rique permet aux disques d'&ecirc;tre
	    d&eacute;plac&eacute;s d'un emplacement &agrave; un autre sans
	    confusion possible.</para>
	</listitem>

	<listitem>
	  <para>La ligne <emphasis>volume</emphasis> d&eacute;crit un volume.
	    Le seul attribut n&eacute;cessaire est le nom, dans notre cas
	    <emphasis>myvol</emphasis>.</para>
	</listitem>

	<listitem>
	  <para>La ligne <emphasis>plex</emphasis> d&eacute;finit
	    une plex.  Le seul param&egrave;tre requit est l'organisation,
	    dans ce cas <emphasis>concat</emphasis>.  Aucun nom n'est
	    n&eacute;cessaire: le syst&egrave;me g&eacute;n&egrave;re
	    automatiquement un nom &agrave; partir du nom de volume en
	    ajoutant le suffixe
	    <emphasis>.p</emphasis><emphasis>x</emphasis>, o&ugrave;
	    <emphasis>x</emphasis> est le nombre de plexes dans le volume.
	    Donc cette plex sera appel&eacute;e
	    <emphasis>myvol.p0</emphasis>.</para>
	</listitem>

	<listitem>
	  <para>La ligne <emphasis>sd</emphasis> d&eacute;crit un
	    sous-disque.  Les sp&eacute;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&eacute;cessaire: le
	    syst&egrave;me assignera automatiquement des noms
	    d&eacute;riv&eacute;s du nom de la plex en ajoutant le
	    suffixe <emphasis>.s</emphasis><emphasis>x</emphasis>,
	    o&ugrave; <emphasis>x</emphasis> est le nombre de sous-disques
	    dans la plex.  Donc Vinum donnera le nom
	    <emphasis>myvol.p0.s0</emphasis> &agrave; ce sous-disque.</para>
	</listitem>
      </itemizedlist>

      <para>Apr&egrave;s avoir trait&eacute; ce fichier
	&man.vinum.8; affiche ce qui suit:</para>

      <programlisting>
      &prompt.root; vinum -&gt; <command>create config1</command>
      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</programlisting>

      <para>Cette sortie affiche une br&egrave;ve liste du format
	&man.vinum.8;.  Elle est repr&eacute;sent&eacute;e graphiquement
	dans <xref linkend="vinum-simple-vol">.</para>

      <para>
	<figure id="vinum-simple-vol">
	  <title>Un simple volume Vinum</title>
	  <graphic fileref="vinum/vinum-simple-vol">
	</figure>
      </para>

      <para>Cette figure, et celles qui suivent, repr&eacute;sentent un
	volume qui contient les plexes, qui &agrave; leur tour contiennent
	les sous-disques.  Dans cet exemple trivial, le volume
	contient une plex, et la plex contient un sous-disque.</para>

      <para>Ce volume particulier ne pr&eacute;sente aucun avantage
	sp&eacute;cifique par rapport &agrave; 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&eacute;rence dans l'organisation du stockage des
	donn&eacute;es par rapport &agrave; une partition de disque
	conventionnelle.  Les sections suivantes pr&eacute;senteront
	diverses m&eacute;thodes de configuration plus
	int&eacute;ressantes.</para>
    </sect2>

    <sect2>
      <title>Robustesse accrue: le mode miroir</title>
      <para>La robustesse d'un volume peut &ecirc;tre
	augment&eacute;e par le mode miroir.  Quand on impl&eacute;mente
	un volume en mode miroir, il est important de s'assurer que
	les sous-disques de chaque plex sont sur des disques
	diff&eacute;rents, de sorte qu'une panne disque ne mette hors service
	les deux plexes.  La configuration suivante place en mode
	miroir un volume:</para>

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

      <para>Dans cet exemple, il n'&eacute;tait pas n&eacute;cessaire de
	sp&eacute;cifier une d&eacute;finition de disque
	<emphasis>a</emphasis> &agrave; nouveau,
	puisque Vinum garde trace de tous les objets dans sa base de
	donn&eacute;es de configuration.  Apr&egrave;s le traitement de cette
	d&eacute;finition, la configuration ressemble &agrave;:</para>


      <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</programlisting>

      <para><xref linkend="vinum-mirrored-vol"> pr&eacute;sente la
	structure sous forme graphique.</para>

      <para>
	<figure id="vinum-mirrored-vol">
	  <title>Un volume Vinum en mode miroir</title>
	  <graphic fileref="vinum/vinum-mirrored-vol">
	</figure>
      </para>

      <para>Dans cet exemple, chaque plex contient un espace
	d'adressage de 512&nbsp;MO.  Comme dans l'exemple
	pr&eacute;c&eacute;dent, chaque plex contient seulement un seul
	sous-disque.</para>
    </sect2>

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

	<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</programlisting>

      <para>Comme pr&eacute;c&eacute;demment, il n'est pas n&eacute;cessaire de
	d&eacute;finir les disques qui sont d&eacute;j&agrave; connus de Vinum.
	Apr&egrave;s traitement de cette d&eacute;finition, la configuration
	ressemble &agrave;:</para>

      <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</programlisting>

      <para>
	<figure id="vinum-striped-vol">
	  <title>Un volume Vinum segment&eacute;</title>
	  <graphic fileref="vinum/vinum-striped-vol">
	</figure>
      </para>

      <para>Ce volume est repr&eacute;sent&eacute; sur
	<xref linkend="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.</para>
    </sect2>

    <sect2>
      <title>Robustesse et performances</title>
      <para><anchor id="vinum-resilience">Avec suffisamment de
	mat&eacute;riel, il est possible de cr&eacute;er des volumes qui
	pr&eacute;senteront une robustesse et des performances accrues
	compar&eacute;s aux partitions UNIX&trade; standards.  Un fichier
	de configuration pourrait &ecirc;tre:</para>

      <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</programlisting>

      <para>Les sous-disques de la seconde plex sont d&eacute;cal&eacute;s
	de deux disques par rapport &agrave; ceux de la premi&egrave;re plex:
	cela aide &agrave; s'assurer que les &eacute;critures ne vont pas sur
	les m&ecirc;me sous-disques m&ecirc;me si un transfert s'effectue sur
	les deux disques.</para>

      <para><xref linkend="vinum-raid10-vol"> repr&eacute;sente la structure
	de ce volume.</para>

      <para>
	<figure id="vinum-raid10-vol">
	  <title>Un volume Vinum en mode miroir segment&eacute;</title>
	  <graphic fileref="vinum/vinum-raid10-vol">
        </figure>
      </para>
    </sect2>
  </sect1>

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

    <para>Les noms pourront contenir tout caract&egrave;re non vide, mais il
      est recommand&eacute; de se cantonner aux lettres, chiffres ou le
      caract&egrave;re soulign&eacute;.  Les noms de volumes, plexes et
      sous-disques peuvent contenir jusqu'&agrave; 64 caract&egrave;res,
      et le nom des disques 32 caract&egrave;res.</para>

    <para><indexterm><primary>/dev/vinum</primary></indexterm>
      On assigne &agrave; chaque objet Vinum un fichier sp&eacute;cial de
      p&eacute;riph&eacute;rique dans la hi&eacute;rarchie
      <filename>/dev/vinum</filename>.  La configuration pr&eacute;sent&eacute;e
      plus haut aurait fait &agrave; Vinum cr&eacute;er les fichiers
      sp&eacute;ciaux de p&eacute;riph&eacute;rique suivants:</para>

    <itemizedlist>
      <listitem>
	<para>Les p&eacute;riph&eacute;riques de contr&ocirc;le
	  <devicename>/dev/vinum/control</devicename> et
	  <devicename>/dev/vinum/controld</devicename>, qui sont
	  respectivement utilis&eacute;s par &man.vinum.8;et le
	  &ldquo;daemon&rdquo; Vinum.</para>
      </listitem>

      <listitem>
	<para>Les entr&eacute;es des p&eacute;riph&eacute;riques en mode
	  bloc et caract&egrave;res par chaque volume.  Ce sont les
	  p&eacute;riph&eacute;riques principaux utilis&eacute;s
	  par Vinum.  Les noms de p&eacute;riph&eacute;riques en mode
	  bloc sont le nom du volume, alors que les noms de
	  p&eacute;riph&eacute;riques en mode caract&egrave;re suivent la
	  tradition BSD de faire pr&eacute;c&eacute;der le nom de la lettre
	  <emphasis>r</emphasis>.  Donc la configuration pr&eacute;c&eacute;dent
	  inclurait les p&eacute;riph&eacute;riques en mode bloc
	  <devicename>/dev/vinum/myvol</devicename>,
	  <devicename>/dev/vinum/mirror</devicename>,
	  <devicename>/dev/vinum/striped</devicename>,
	  <devicename>/dev/vinum/raid5</devicename> et
	  <devicename>/dev/vinum/raid10</devicename>, et les
	  p&eacute;riph&eacute;riques en mode caract&egrave;res
	  <devicename>/dev/vinum/rmyvol</devicename>,
	  <devicename>/dev/vinum/rmirror</devicename>,
	  <devicename>/dev/vinum/rstriped</devicename>,
	  <devicename>/dev/vinum/rraid5</devicename> et
	  <devicename>/dev/vinum/rraid10</devicename>.
	  Un probl&egrave;me &eacute;vident appara&icirc;t ici: il est
	  possible d'avoir deux volumes appel&eacute;s
	  <emphasis>r</emphasis> et <emphasis>rr</emphasis>, mais il y
	  aurait un conflit lors de la cr&eacute;ation du fichier
	  sp&eacute;cial de p&eacute;riph&eacute;rique
	  <devicename>/dev/vinum/rr</devicename>: c'est le
	  p&eacute;riph&eacute;rique en mode caract&egrave;re du volume
	  <emphasis>r</emphasis> ou le p&eacute;riph&eacute;rique en mode bloc
	  du volume <emphasis>rr</emphasis>?  Actuellement Vinum ne
	  r&eacute;sout pas ce conflit: le premier volume d&eacute;fini
	  obtiendra le nom.</para>
      </listitem>

      <listitem>
	<para>Un r&eacute;pertoire <devicename>/dev/vinum/drive</devicename>
	  avec des entr&eacute;es pour chaque disque.  Ces entr&eacute;es
	  sont en fait des liens symboliques vers les fichiers
	  sp&eacute;ciaux de p&eacute;riph&eacute;rique de
	  disque correspondants.</para>
      </listitem>

      <listitem>
	<para>Un r&eacute;pertoire <filename>/dev/vinum/volume</filename> avec
	  des entr&eacute;es pour chaque volume.  Il contient des
	  sous-r&eacute;pertoires pour chaque plex, qui &agrave; leur tour
	  contiennent des sous-r&eacute;pertoires pour leurs
	  sous-disques.</para>
      </listitem>

      <listitem>
	<para>Les r&eacute;pertoires <devicename>/dev/vinum/plex</devicename>,
	  <devicename>/dev/vinum/sd</devicename>, et
	  <devicename>/dev/vinum/rsd</devicename>, qui contiennent les
	  fichiers sp&eacute;ciaux de p&eacute;riph&eacute;rique en mode bloc
	  pour chaque plex et les fichiers sp&eacute;ciaux de
	  p&eacute;riph&eacute;rique en mode bloc
	  et caract&egrave;re pour chaque sous-disque.</para>
      </listitem>
    </itemizedlist>

    <para>Par exemple, consid&eacute;rons le fichier de configuration
      suivant:</para>
	<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</programlisting>

    <para>Apr&egrave;s traitement de ce fichier, &man.vinum.8;
      cr&eacute;e la structure suivante dans
      <filename>/dev/vinum</filename>:</para>

    <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 -&gt; /dev/sd1h
    lrwxr-xr-x  1 root  wheel  9 Apr 13 16:46 drive2 -&gt; /dev/sd2h
    lrwxr-xr-x  1 root  wheel  9 Apr 13 16:46 drive3 -&gt; /dev/sd3h
    lrwxr-xr-x  1 root  wheel  9 Apr 13 16:46 drive4 -&gt; /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</programlisting>

    <para>Bien qu'il soit recommand&eacute; de ne pas donner de nom
      sp&eacute;cifique aux plexes et sous-disques, les disques Vinum doivent
      avoir un nom.  Cela rend possible de d&eacute;placer un disque &agrave; un
      emplacement diff&eacute;rent et qu'il soit toujours reconnu
      automatiquement.  Les noms de disques peuvent avoir jusqu'&agrave; 32
      caract&egrave;res.</para>

    <sect2>
      <title>Cr&eacute;ation de syst&egrave;mes de fichiers</title>
	<para>Les volumes apparaissent pour le syst&egrave;me comme des
	  disques, avec une seule exception.  Contrairement aux
	  disques UNIX&trade;, Vinum ne partitionne pas les volumes, qui
	  ne contiennent donc pas de table de partitionnement.  Cela a
	  demand&eacute; de modifier certains utilitaires disque, en
	  particulier &man.newfs.8;, qui auparavant tentait
	  d'interpr&eacute;ter la derni&egrave;re lettre du nom de volume Vinum
	  comme un identifiant de partition.  Par exemple, un disque
	  peut avoir un nom comme <devicename>/dev/ad0a</devicename>$
	  ou <devicename>/dev/da2h</devicename>.  Ces noms
	  repr&eacute;sentent respectivement la premi&egrave;re partition
	  (<devicename>a</devicename>) sur le premier (0) disque IDE
	  (<devicename>ad</devicename>) la la huiti&egrave;me partition
	  (<devicename>h</devicename>) sur le troisi&egrave;me (2)
	  disque SCSI (<devicename>da</devicename>).  En revanche,
	  un volume Vinum pourra &ecirc;tre appel&eacute;
	  <devicename>/dev/vinum/concat</devicename>, un nom qui n'a
	  pas de relation avec un nom de partition.</para>

	<para>Normalement, &man.newfs.8; interpr&egrave;te le nom du disque
	  et se plaint s'il ne peut le comprendre.  Par
	  exemple:</para>

	<screen>&prompt.root; <userinput>newfs /dev/vinum/concat</userinput>
newfs: /dev/vinum/concat: can't figure out file system partition</screen>

	<para>Afin de cr&eacute;er un syst&egrave;me de fichiers sur ce volume,
	  utilisez l'option <option>-v</option> de
	  &man.newfs.8;:</para>

	<screen>&prompt.root; <userinput>newfs -v /dev/vinum/concat</userinput></screen>

    </sect2>
  </sect1>

  <sect1 id="vinum-config">
    <title>Configuration de Vinum</title>
    <para>Le noyau <filename>GENERIC</filename> ne contient pas le
      support Vinum.  Il est possible de compiler un noyau sp&eacute;cial
      qui inclut vinum, mais cela n'est pas recommand&eacute;.  La
      m&eacute;thode standard de lancement de Vinum est d'utiliser un module du
      noyau (<acronym>kld</acronym>).  Vous n'avez m&ecirc;me pas
      besoin d'utiliser &man.kldload.8; pour Vinum: quand vous lancez
      &man.vinum.8;, il contr&ocirc;le si le module a &eacute;t&eacute;
      charg&eacute; ou non, si ce n'est pas le cas, il le charge
      automatiquement.</para>

    <sect2>
      <title>D&eacute;marrage</title>
	<para>Vinum stocke l'information de configuration sur les
	  tranches des disques sous la m&ecirc;me forme que dans les
	  fichiers de configuration.  En lisant &agrave; partir de la base
	  de donn&eacute;es de configuration, Vinum reconna&icirc;t un certain
	  nombre de mots cl&eacute;s qui ne sont pas autoris&eacute;s dans
	  les fichiers de configuration.  Par exemple, une
	  configuration de disque pourrait contenir le texte
	  suivant:</para>

	<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</programlisting>

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

      <sect3>
	<title>D&eacute;marrage automatique</title>
	  <para>Afin de lancer automatiquement Vinum au d&eacute;marrage du
	    syst&egrave;me, assurez-vous d'avoir la ligne suivante dans votre
	    fichier <filename>/etc/rc.conf</filename>:</para>

	<programlisting>start_vinum="YES"		# set to YES to start vinum</programlisting>

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

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

      </sect3>
    </sect2>
  </sect1>
</chapter>
