path: root/it_IT.ISO8859-15/books/handbook/vinum/chapter.sgml

<?xml version="1.0" encoding="iso-8859-15" standalone="no"?>
<!--
     The FreeBSD Italian Documentation Project

     $FreeBSD$
     Original revision: 1.37
-->

<chapter id="vinum-vinum">
  <chapterinfo>
      <authorgroup>
        <author>
          <firstname>Greg</firstname>

          <surname>Lehey</surname>

          <contrib>Originariamente scritto da </contrib>
        </author>
      </authorgroup>
  </chapterinfo>

  <title>Il Gestore di Volumi Vinum</title>

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

    <para>Qualunque siano i dischi che hai, ci sono sempre dei problemi
      potenziali:</para>

    <itemizedlist>
      <listitem>
        <para>Potrebbero essere troppo piccoli.</para>
      </listitem>

      <listitem>
        <para>Potrebbero essere troppo lenti.</para>
      </listitem>

      <listitem>
        <para>Potrebbero essere troppo inaffidabili.</para>
      </listitem>
    </itemizedlist>

    <para>Un modo in cui alcuni utenti salvaguardano sè stessi contro
      questi problemi è attraverso l'uso di dischi multipli, e
      talvolta ridondanti.</para>

    <para>In aggiunta a supportare diverse schede e controller per sistemi RAID
      hardware, il sistema FreeBSD base include il gestore di volumi Vinum, un
      driver di dispositivo a blocchi che implementa dischi virtuali.</para>

    <para>Vinum fornisce più flessibilità, prestazioni, e
      affidabilità rispetto all'archiviazione su disco tradizionale e
      implementa i modelli RAID-0, RAID-1, e RAID-5 sia singolarmente che in
      combinazione.</para>

    <para>Questo capitolo fornisce una panoramica sui potenziali problemi
      dell'archiviazione su disco tradizionale e un'introduzione al gestore
      di volumi Vinum.</para>
  </sect1>

  <sect1 id="vinum-intro">
    <title>Dischi Troppo Piccoli</title>

    <indexterm><primary>Vinum</primary></indexterm>
    <indexterm>
      <primary>RAID</primary>
      <secondary>software</secondary>
    </indexterm>

    <para><emphasis>Vinum</emphasis> è un <emphasis>Volume
      Manager</emphasis>, ovvero un driver virtuale di disco che si occupa dei
      tre problemi indicati nella sinossi.  Diamo un'occhiata in dettaglio a
      questi problemi, per i quali sono state proposte e implementate varie
      soluzioni.</para>

    <para>I dischi stanno diventando sempre più grandi, ma questo
      è vero anche per le necessità di spazio per i dati.  Spesso
      sentirai il bisogno di avere un file system più grande dei dischi
      che possiedi.  Effettivamente questo problema non è così
      grave come lo era dieci anni fa, ma è sempre presente.  Alcuni
      sistemi risolvono la questione creando un dispositivo astratto che
      ripartisce i suoi dati su vari dischi.</para>
  </sect1>

  <sect1 id="vinum-access-bottlenecks">
    <title>Colli di Bottiglia nell'Accesso</title>

    <para>I moderni sistemi hanno frequentemente la necessità di
      accedere ai dati in modo concorrente.  Ad esempio, un grande server FTP o
      HTTP può avere migliaia di sessioni concorrenti e molteplici
      connessioni da 100&nbsp;Mbit/s verso il mondo esterno, ben oltre il
      transfer rate (velocità di trasferimento) che la maggior parte dei
      dischi può sostenere.</para>

    <para>I dischi odierni possono trasferire sequenzialmente dati fino a
      70&nbsp;MB/s, ma questo valore ha poca importanza in un ambiente dove
      molti processi indipendenti accedono al disco, in quanto raggiungerebbero
      solo una frazione di quella velocità.  In questi casi è
      più interessante vedere il problema dal punto di vista del
      sottosistema dischi: il parametro importante è il carico che il
      trasferimento pone sul sottosistema, in altre parole il tempo per cui il
      trasferimento occupa i dischi necessari per lo stesso.</para>

    <para>In ogni trasferimento da disco il drive deve prima posizionare le
      testine, poi aspettare che il primo settore passi sotto la testina di
      lettura e solo dopo può effettuare il trasferimento.  Queste azioni
      possono essere considerate atomiche: non ha alcun senso
      interromperle.</para>

    <para><anchor id="vinum-latency"/>Considera un tipico trasferimento di circa
      10 kB: l'attuale generazione di dischi ad alte prestazioni può
      posizionare le testine in circa 3,5&nbsp;ms.  I dischi più veloci
      ruotano a 15.000&nbsp;rpm, quindi la latenza media rotazionale (mezzo
      giro) è di 2&nbsp;ms.  A 70&nbsp;MB/s, il trasferimento in
      sé occupa circa 150&nbsp;&mu;s, quasi nulla in confronto al tempo
      di posizionamento. In questo caso il transfer rate effettivo può
      scendere fino a poco oltre 1&nbsp;MB/s e questo è chiaramente molto
      dipendente dalla dimensione del trasferimento.</para>

    <para>La tradizionale e ovvia soluzione a questo collo di bottiglia è
      <quote>più assi</quote>: invece di usare un grande disco si usano
      molti piccoli dischi con la stessa dimensione totale.  Ogni disco è
      capace di posizionarsi e trasferire dati indipendentemente quindi la
      velocità effettiva aumenta di un fattore vicino al numero di dischi
      usati.</para>

    <para>L'esatto fattore di miglioramento è, ovviamente, più
      piccolo del numero di dischi: benché ogni disco sia capace di
      trasferire in parallelo non c'è modo di assicurare che le richieste
      siano distribuite uniformemente tra tutti i dischi.  Inevitabilmente il
      carico su uno dei dischi è più alto che sugli altri.</para>

    <indexterm><primary>concatenazione dei dischi</primary></indexterm>
    <indexterm>
      <primary>Vinum</primary>
      <secondary>concatenazione</secondary>
    </indexterm>

    <para>L'uniformità della distribuzione del carico sui dischi è
      fortemente dipendente dal modo in cui i dati sono condivisi tra i dischi
      stessi.  Nella seguente discussione è conveniente pensare allo
      spazio di immagazzinamento come se fosse diviso in un gran numero di
      settori identificati da un indirizzo numerico, come pagine in un libro.
      Il metodo più ovvio è di dividere il disco virtuale in
      gruppi di settori consecutivi della dimensione dei dischi fisici e
      immagazzinarli in questa maniera, come strappare un grosso libro in
      piccole sezioni.  Questo metodo è chiamato
      <emphasis>concatenazione</emphasis> e ha il vantaggio di non avere
      particolari richieste sulla dimensione degli specifici dischi.
      Funziona bene quando l'accesso al
      disco virtuale è ben ripartito tra tutto il suo spazio di
      indirizzamento.  Quando l'accesso è concentrato in una piccola area
      il miglioramento è meno marcato.  La <xref linkend="vinum-concat"/>
      illustra la sequenza in cui le unità di immagazzinamento sono
      allocate nell'organizzazione concatenata.</para>

    <para>
      <figure id="vinum-concat">
        <title>Organizzazione Concatenata</title>

        <graphic fileref="vinum/vinum-concat"/>
      </figure>
    </para>

    <indexterm><primary>striping dei dischi</primary></indexterm>
    <indexterm>
      <primary>Vinum</primary>
      <secondary>striping</secondary>
    </indexterm>
    <indexterm>
      <primary>RAID</primary>
    </indexterm>
    <indexterm>
      <primary>RAID</primary>
      <secondary>livello 0</secondary>
    </indexterm>
    <indexterm><primary>RAID-0</primary></indexterm>

    <para>Un metodo alternativo è dividere lo spazio di indirizzamento in più
      piccole componenti di egual dimensione e immagazzinarle sequenzialmente su
      differenti dispositivi.  Per esempio i primi 256 settori potrebbero essere
      immagazzinati sul primo disco, i seguenti 256 settori sul disco seguente e
      così via.  Dopo aver immagazzinato i dati sull'ultimo disco il
      processo si ripete finché i dischi non sono pieni.  Questo
      mappamento è chiamato <emphasis>striping</emphasis> (letteralmente
      "a bande") o <acronym>RAID-0</acronym>
      <footnote>
        <para><acronym>RAID</acronym> significa <emphasis>Redundant Array of
          Inexpensive Disks</emphasis> (insieme ridondante di dischi non
          costosi) e offre varie forme di tolleranza ai problemi.  Nel caso del
          <acronym>RAID-0</acronym> il termine è leggermente fuorviante:
          in effetti non dà alcuna ridondanza.</para>
      </footnote>.
      Lo striping richiede qualche sforzo aggiuntivo per localizzare i dati e
      può causare carico di I/O aggiuntivo quando il trasferimento
      è distribuito tra vari dischi, ma aiuta il carico a essere ben
      distribuito tra i vari dischi.  La <xref linkend="vinum-striped"/> illustra
      la sequenza in cui i blocchi di dati sono allocati nell'organizzazione in
      striping.</para>

    <para>
      <figure id="vinum-striped">
        <title>Organizzazione in Striping</title>

        <graphic fileref="vinum/vinum-striped"/>
      </figure>
    </para>
  </sect1>

  <sect1 id="vinum-data-integrity">
    <title>Integrità dei Dati</title>

    <para>L'ultimo problema dei dischi attuali è che sono inaffidabili.
      Benché la loro affidabilità sia aumentata tremendamente
      durante gli ultimi anni sono tuttora il componente di un server che ha
      la maggior probabilità di rompersi.  Quando succede i risultati
      possono essere catastrofici: rimpiazzare un disco rotto e riempirlo dei
      dati originari può richiedere giorni.</para>

    <indexterm><primary>mirroring dei dischi</primary></indexterm>
    <indexterm>
      <primary>Vinum</primary>
      <secondary>mirroring</secondary>
    </indexterm>
    <indexterm>
      <primary>RAID</primary>
      <secondary>livello 1</secondary>
    </indexterm>
    <indexterm><primary>RAID-1</primary></indexterm>

    <para>Il metodo tradizionale per affrontare questo problema si chiama
      <emphasis>mirroring</emphasis> (letteralmente "specchiatura") e consiste
      nel tenere due copie dei dati su hardware fisici differenti.  Con
      l'avvento dei livelli <acronym>RAID</acronym> questa tecnica è
      stata chiamata <acronym>RAID</acronym> di livello 1 o
      <acronym>RAID-1</acronym>.  Ogni scrittura su disco scrive in entrambe le
      locazioni; una lettura può essere soddisfatta da entrambi quindi se
      un disco si rompe i dati sono sempre disponibili sull'altro disco.</para>

    <para>Il mirroring ha due problemi:</para>

    <itemizedlist>
      <listitem>
        <para>Il prezzo.  Richiede il doppio dello spazio di
          immagazzinamento delle soluzioni non ridondanti.</para>
      </listitem>

      <listitem>
        <para>L'impatto sulle prestazioni.  La scrittura deve essere
          compiuta su entrambi i dischi quindi la banda occupata raddoppia.
          Le letture non soffrono di problemi sulle prestazioni: possono
          perfino essere più veloci.</para>
      </listitem>
    </itemizedlist>

    <indexterm>
      <primary>Vinum</primary>
      <secondary>striping con parità</secondary>
    </indexterm>
    <para><indexterm><primary>RAID-5</primary></indexterm>

      Una soluzione alternativa è la
      <emphasis>parità</emphasis>, implementata nel
      <acronym>RAID</acronym> di livello 2, 3, 4 e 5.  Di questi, il
      <acronym>RAID-5</acronym> è il più interessante.  La sua
      implementazione in Vinum è una variante dell'organizzazione in
      striping che dedica un blocco di ogni banda alla parità degli
      altri blocchi. Per come è implementato in Vinum, ogni blocco
      <acronym>RAID-5</acronym> è simile a un blocco in striping, con
      la differenza che implementa il <acronym>RAID-5</acronym> includendo un
      blocco di parità per ogni banda.  Come richiesto dal
      <acronym>RAID-5</acronym> la locazione di questi blocchi di parità
      cambia da ogni banda alla successiva.  I numeri nei blocchi dati indicano
      il numero dei blocchi relativi.</para>

    <para>
      <figure id="vinum-raid5-org">
        <title>Organizzazione RAID-5</title>

        <graphic fileref="vinum/vinum-raid5-org"/>
      </figure>
    </para>

    <para>Comparandolo al mirroring, il <acronym>RAID-5</acronym> ha il
      vantaggio di richiedere molto meno spazio di immagazzinamento.  La
      velocità di lettura è simile all'organizzazione in
      striping, ma in scrittura l'accesso è significativamente più
      lento, circa il 25% della performance di lettura.  Se uno dei dischi si
      rompe l'aggregato continua a lavorare con performance peggiorate: la
      lettura da uno dei dischi rimanenti continua normalmente, ma la lettura
      dal disco rotto è ricalcolata dai corrispondenti blocchi dei
      dischi rimanenti.</para>
  </sect1>

  <sect1 id="vinum-objects">
    <title>Oggetti Vinum</title>

    <para>Per risolvere questi problemi Vinum implementa una categoria di
      oggetti a quattro livelli:</para>

    <itemizedlist>
      <listitem>
        <para>L'oggetto più visibile è il disco virtuale,
          chiamato <emphasis>volume</emphasis>.  I volumi hanno essenzialmente
          le stesse proprietà di un disco &unix;, benché ci
          sia qualche differenza minore.  Non hanno limiti di dimensione.</para>
      </listitem>

      <listitem>
        <para>I volumi sono composti da <emphasis>plex</emphasis>, ognuno dei
          quali rappresenta il completo spazio di indirizzamento del volume.
          È quindi questo il livello della gerarchia che gestisce la
          ridondanza dei dati.  Pensa ai plex come a singoli dischi collegati
          tra loro in mirroring, ognuno contenente gli stessi dati.</para>
      </listitem>

      <listitem>
        <para>Dato che Vinum vive all'interno del framework &unix; di
          immagazzinamento dei dati sarebbe possibile utilizzare le partizioni
          &unix; come blocchi basilari per costruire i plex multidisco, ma
          questo approccio sarebbe in effetti troppo poco flessibile: i dischi
          &unix; possono avere solo un limitato numero di partizioni; al
          contrario Vinum suddivide le singole partizioni &unix;
          (<emphasis>drive</emphasis>, ovvero dischi) in aree contigue chiamate
          <emphasis>subdisks</emphasis> (sottodischi), che sono a loro volta
          utilizzati come elementi per costruire i plex.</para>
      </listitem>

      <listitem>
        <para>I sottodischi risiedono su <emphasis>drive</emphasis> Vinum, che
          attualmente sono partizioni &unix;.  I drive Vinum possono
          contenere qualsiasi quantità di sottodischi.  Con l'eccezione
          di una piccola area all'inizio del drive, che è usata per
          immagazzinare informazioni sulla configurazione e sullo stato,
          l'intero drive è disponibile per l'immagazzinamento
          dei dati.</para>
      </listitem>
    </itemizedlist>

    <para>La sezione seguente descrive come gli oggetti sopra discussi possano
      dare le funzionalità richieste.</para>

    <sect2>
      <title>Considerazioni sulle Dimensioni dei Volumi</title>

      <para>I plex possono contenere molteplici sottodischi distribuiti tra
        tutti i drive presenti nella configurazione di Vinum, questo permette
        alla dimensione dei plex, e quindi anche dei volumi, di non essere
        limitata dalla dimensione dei singoli dischi.</para>
    </sect2>

    <sect2>
      <title>Immagazzinamento Ridondante dei Dati</title>

      <para>Vinum implementa il mirroring collegando più plex allo stesso
        volume, ogni plex contiene la rappresentazione di tutti i dati del
        volume.  Un volume può contenere da uno ad otto plex.</para>

      <para>Nonostante un plex rappresenti i dati di un volume per intero,
        è possibile che parti di questa rappresentazione vengano a
        mancare o per scelta (non definendo dei sottodischi per alcune parti del
        plex) o per accidente (come risultato della rottura del disco che le
        conteneva).  Finché almeno un plex contiene i dati di tutto lo
        spazio d'indirizzamento del volume, il volume stesso è
        completamente funzionale.</para>
    </sect2>

    <sect2>
      <title>Considerazioni sulle Prestazioni</title>

      <para>Vinum implementa sia la concatenazione che lo striping al livello di
        plex:</para>

      <itemizedlist>
        <listitem>
          <para>Un <emphasis>plex concatenato</emphasis> usa lo spazio di
            indirizzamento di ogni sottodisco a turno.</para>
        </listitem>

        <listitem>
          <para>Un <emphasis>plex in striping</emphasis> suddivide i dati tra
            ogni sottodisco.  I sottodischi devono tutti avere la stessa
            dimensione e devono essere presenti almeno due sottodischi
            perché esista differenza da un plex concatenato.</para>
        </listitem>
      </itemizedlist>
    </sect2>

    <sect2>
      <title>Quale Organizzazione per i Plex?</title>

      <para>La versione di Vinum distribuita con FreeBSD &rel.current;
        implementa due tipi di plex:</para>

      <itemizedlist>
        <listitem>
          <para>I plex concatenati, che sono i più flessibili: possono
            contenere qualsiasi numero di sottodischi e questi possono avere
            qualsiasi dimensione.  Il plex può essere esteso aggiungendo
            sottodischi.  Richiede meno tempo di <acronym>CPU</acronym> di un
            plex in striping, benché la differenza in carico di
            <acronym>CPU</acronym> non sia misurabile.  D'altro canto sono
            più suscettibili agli hot spot (letteralmente <quote>zona
            calda</quote>): ovvero situazioni in cui un disco è molto attivo mentre
            gli altri sono fermi.</para>
        </listitem>

        <listitem>
          <para>Il più grande vantaggio dei plex in striping
            (<acronym>RAID-0</acronym>) è la loro capacità di
            ridurre gli hot spot: scegliendo una dimensione di striping ottimale
            (circa 256&nbsp;kB) si può ridistribuire il carico sui drive.
            Gli svantaggi di questo approccio sono codice più complesso e
            restrizioni sui sottodischi: devono essere tutti della stessa
            dimensione, inoltre estendere il plex aggiungendo sottodischi
            è così complicato che attualmente Vinum non lo
            implementa.  Vinum aggiunge anche un'ulteriore restrizione
            elementare: un plex in striping deve contenere almeno due
            sottodischi, dato che sarebbe altrimenti indistinguibile da un plex
            concatenato.</para>
        </listitem>
      </itemizedlist>

      <para>La <xref linkend="vinum-comparison"/> riassume vantaggi e svantaggi
        di ogni tipo di organizzazione dei plex.</para>

      <table id="vinum-comparison" frame="none">
        <title>Organizzazione dei Plex Vinum</title>

        <tgroup cols="5">
          <thead>
            <row>
              <entry>Tipo di plex</entry>

              <entry>Sottodischi minimi</entry>

              <entry>Sottodischi aggiungibili</entry>

              <entry>Dimensioni forzatamente uguali</entry>

              <entry>Applicazione</entry>
            </row>
          </thead>

          <tbody>
            <row>
              <entry>concatenato</entry>

              <entry>1</entry>

              <entry>sì</entry>

              <entry>no</entry>

              <entry>Immagazzinamento di grandi moli di dati con la massima
                flessibilità e prestazioni moderate</entry>
            </row>

            <row>
              <entry>striping</entry>

              <entry>2</entry>

              <entry>no</entry>

              <entry>sì</entry>

              <entry>Alte prestazioni in casi di accessi altamente
                concorrenti</entry>
            </row>
          </tbody>
        </tgroup>
      </table>
    </sect2>
  </sect1>

  <sect1 id="vinum-examples">
    <title>Alcuni Esempi</title>

    <para>Vinum mantiene un <emphasis>database della configurazione</emphasis>
      che descrive gli oggetti del sistema conosciuti.  Inizialmente l'utente
      crea il database della configurazione da uno o più file di
      configurazione, con l'aiuto del programma &man.vinum.8;.  Vinum
      immagazzina una copia del database di configurazione in ogni slice del
      disco (che Vinum chiama <emphasis>device</emphasis>, ovvero
      <quote>dispositivo</quote>) sotto il suo controllo.
      Questo database è aggiornato a ogni cambio
      di stato in modo che un riavvio possa recuperare accuratamente lo stato di
      ogni oggetto Vinum.</para>

    <sect2>
      <title>Il File di Configurazione</title>

      <para>Il file di configurazione descrive singoli oggetti Vinum.  La
        definizione di un semplice volume potrebbe essere:</para>

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

      <para>Questo file descrive quattro oggetti Vinum:</para>

      <itemizedlist>
        <listitem>
          <para>La linea <emphasis>drive</emphasis> descrive la partizione del
            disco (<emphasis>drive</emphasis>) e la sua locazione relativa
            all'hardware sottostante.  Gli viene assegnato il nome simbolico
            <emphasis>a</emphasis>.  Questa separazione dei nomi simbolici dai
            nomi di dispositivo permette di muovere i dischi da una locazione ad
            un'altra senza confusione.</para>
        </listitem>

        <listitem>
          <para>La linea <emphasis>volume</emphasis> descrive un volume.
           L'unico attributo richiesto è il nome, in questo caso
           <emphasis>myvol</emphasis>.</para>
        </listitem>

        <listitem>
          <para>La linea <emphasis>plex</emphasis> definisce un plex.
            L'unico parametro richiesto è il tipo di organizzazione, in
            questo caso <emphasis>concat</emphasis>.  Non è necessario
            un nome: il sistema genera un nome automaticamente a partire dal
            nome del volume, aggiungendo un suffisso
            <emphasis>.p</emphasis><emphasis>x</emphasis>, dove
            <emphasis>x</emphasis> indica il numero del plex nel volume.  Il
            plex verrà quindi chiamato
            <emphasis>myvol.p0</emphasis>.</para>
        </listitem>

        <listitem>
          <para>La linea <emphasis>sd</emphasis> descrive un sottodisco.
            Le specifiche minime sono il nome del drive su cui immagazzinarlo e
            la lunghezza del sottodisco.  Come per i plex non è
            necessario un nome: il sistema assegna automaticamente nomi
            derivati dal nome del plex, aggiungendo il suffisso
            <emphasis>.s</emphasis><emphasis>x</emphasis>, dove
            <emphasis>x</emphasis> indica il numero del sottodisco nel plex,
            quindi Vinum darà a questo sottodisco il nome di
            <emphasis>myvol.p0.s0</emphasis>.</para>
        </listitem>
      </itemizedlist>

      <para>Dopo aver elaborato questo file, &man.vinum.8; produce il seguente
        output:</para>

      <programlisting width="97">      &prompt.root; vinum -&gt; <userinput>create config1</userinput>
      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>Questo output mostra il formato di elenco breve di &man.vinum.8;,
        che è rappresentato graficamente nella
        <xref linkend="vinum-simple-vol"/>.</para>

      <para>
        <figure id="vinum-simple-vol">
          <title>Un Semplice Volume Vinum</title>

          <graphic fileref="vinum/vinum-simple-vol"/>
        </figure>
      </para>

      <para>Questa figura e quelle che seguono rappresentano un volume
        contenente dei plex che a loro volta contengono dei sottodischi.
        In questo semplice esempio il volume contiene un plex e il plex
        contiene un sottodisco.</para>

      <para>Questo particolare volume non ha specifici vantaggi su una
        convenzionale partizione di disco.  Contiene un singolo plex, quindi non
        è ridondante.  Il plex contiene un solo sottodisco, quindi non
        c'è differenza nell'immagazzinamento dei dati.  Le sezioni
        seguenti mostrano vari metodi di configurazione più
        interessanti.</para>
    </sect2>

    <sect2>
      <title>Aumentare la Resistenza alle Rotture: il Mirroring</title>

      <para>Il mirroring può aumentare, in un volume, la resistenza alle
        rotture.  Quando si definisce un volume in mirroring è importante
        assicurarsi che i sottodischi di ogni plex siano su dischi differenti,
        in modo che la rottura di un drive non blocchi entrambi i plex.  La
        seguente configurazione mostra un volume in mirroring:</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>In questo esempio non è necessario specificare nuovamente la
        definizione del drive <emphasis>a</emphasis>, dato che Vinum mantiene
        traccia di tutti gli oggetti nel suo database di configurazione.  Dopo
        aver elaborato questa definizione, la configurazione appare
        così:</para>


      <programlisting width="97">    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"/> mostra la struttura
        graficamente.</para>

      <para>
        <figure id="vinum-mirrored-vol">
          <title>Un Volume Vinum in Mirroring</title>

          <graphic fileref="vinum/vinum-mirrored-vol"/>
        </figure>
      </para>

      <para>In questo esempio ogni plex contiene l'intero spazio di
        indirizzamento di 512&nbsp;MB.  Come nel precedente esempio ogni plex
        contiene un solo sottodisco.</para>
    </sect2>

    <sect2>
      <title>Ottimizzazione delle Prestazioni</title>

      <para>Il volume in mirroring dell'esempio precedente è più
        resistente alle rotture di un volume non in mirroring, ma le sue
        prestazioni sono inferiori: ogni scrittura sul volume richiede una
        scrittura su ognuno dei drive, utilizzando quindi una maggior frazione
        della banda passante totale dei dischi.  Considerazioni sulle
        prestazioni portano ad un differente approccio: al posto del mirroring,
        i dati vengono posti sul maggior numero di dischi possibile utilizzando lo
        striping.  La seguente configurazione mostra un volume con un plex in
        striping su quattro dischi:</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>Come prima non è necessario definire i drive che Vinum
        già conosce.  Dopo aver elaborato queste definizioni la
        configurazione appare così:</para>

      <programlisting width="92">    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 in Striping</title>

          <graphic fileref="vinum/vinum-striped-vol"/>
        </figure>
      </para>

      <para>Questo volume è rappresentato nella
        <xref linkend="vinum-striped-vol"/>.  L'intensità del colore delle strisce
        indica la posizione all'interno dello spazio di indirizzamento del
        plex: le più chiare all'inizio, le più scure alla
        fine.</para>
    </sect2>

    <sect2>
      <title>Resistenza alle Rotture e Prestazioni</title>

      <para><anchor id="vinum-resilience"/>Con hardware a sufficenza è
        possibile creare volumi con miglioramenti sia nella resistenza alle
        rotture che nelle prestazioni, comparati alle normali partizioni
        &unix;.  Una tipica configurazione potrebbe essere:</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>I sottodischi del secondo plex sono spostati di due posti rispetto a
        quelli del primo plex: questo aumenta le probabilità che le
        scritture non utilizzino lo stesso sottodisco anche nel caso in cui un
        trasferimento utilizzi entrambi i drive.</para>

      <para>La <xref linkend="vinum-raid10-vol"/> rappresenta la struttura di
        questo volume.</para>

      <para>
        <figure id="vinum-raid10-vol">
          <title>Un Volume Vinum in Mirroring e Striping</title>

          <graphic fileref="vinum/vinum-raid10-vol"/>
        </figure>
      </para>
    </sect2>
  </sect1>

  <sect1 id="vinum-object-naming">
    <title>Nomenclatura degli Oggetti</title>

    <para>Come descritto sopra, Vinum assegna nomi di default a plex e
      sottodischi, benché questi possano essere cambiati.  Cambiare il
      nome di default non è raccomandato: l'esperienza con il VERITAS
      volume manager, che permette la nomenclatura arbitraria degli oggetti, ha
      mostrato che questa flessibilità non porta vantaggi significativi e
      può causare confusione.</para>

    <para>I nomi possono contenere ogni carattere non blank (i caratteri di
      spazio, tabulazione, cambio riga) ma è consigliato limitarsi a
      lettere, cifre e il carattere di underscore.  I nomi di volumi,
      plex e sottodischi possono essere
      lunghi fino a 64 caratteri, i nomi di drive invece hanno un massimo di 32
      caratteri.</para>

    <indexterm><primary>/dev/vinum</primary></indexterm>

    <para>I nomi assegnati agli oggetti Vinum sono nella gerarchia
      <filename>/dev/vinum</filename>.
      La configurazione di Vinum mostrata sopra creerebbe i seguenti
      dispositivi:</para>

    <itemizedlist>
      <listitem>
        <para>I dispositivi di controllo
          <filename>/dev/vinum/control</filename> e
          <filename>/dev/vinum/controld</filename>, utilizzati
          rispettivamente da &man.vinum.8; e dal demone Vinum.</para>
      </listitem>

      <listitem>
        <para>Voci di dispositivi a blocchi e a caratteri per ogni volume.
          Questi sono i principali dispositivi utilizzati da Vinum.  I
          dispositivi a blocchi hanno il nome dei relativi volumi, quelli a
          caratteri, seguendo la tradizione BSD, hanno una lettera
          <emphasis>r</emphasis> all'inizio del nome.  Quindi la configurazione
          vista sopra genererebbe i dispositivi a blocchi
          <filename>/dev/vinum/myvol</filename>,
          <filename>/dev/vinum/mirror</filename>,
          <filename>/dev/vinum/striped</filename>,
          <filename>/dev/vinum/raid5</filename> e
          <filename>/dev/vinum/raid10</filename>, e i dispositivi a
          caratteri <filename>/dev/vinum/rmyvol</filename>,
          <filename>/dev/vinum/rmirror</filename>,
          <filename>/dev/vinum/rstriped</filename>,
          <filename>/dev/vinum/rraid5</filename> e
          <filename>/dev/vinum/rraid10</filename>.
          In questo c'è un ovvio problema: è possibile avere due
          volumi chiamati <emphasis>r</emphasis> e <emphasis>rr</emphasis> che
          avrebbero un conflitto nel creare il nodo
          <filename>/dev/vinum/rr</filename>: sarebbe il dispositivo a
          caratteri per il volume <emphasis>r</emphasis> o il dispositivo a
          blocchi per il volume <emphasis>rr</emphasis>?  Attualmente Vinum non
          si interessa di questo conflitto: il volume definito per primo prende
          il nome.</para>
      </listitem>

      <listitem>
        <para>Una directory <filename>/dev/vinum/drive</filename> con voci
        per ogni disco.  Queste voci sono in effetti dei collegamenti simbolici
        ai rispettivi nodi di disco.</para>
      </listitem>

      <listitem>
        <para>Una directory <filename>/dev/vinum/volume</filename> con voci per
          ogni volume.  Contiene sottodirectory per ogni plex, che a loro volta
          contengono sottodirectory per ogni sottodisco.</para>
      </listitem>

      <listitem>
        <para>Le directory <filename>/dev/vinum/plex</filename>,
          <filename>/dev/vinum/sd</filename> e
          <filename>/dev/vinum/rsd</filename> contengono i dispositivi a
          blocchi per ogni plex, dispositivo a blocchi e dispositivo a caratteri
          per ogni sottodisco rispettivamente.</para>
      </listitem>
    </itemizedlist>

    <para>Ad esempio, considera il seguente file di configurazione:</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>Dopo aver elaborato questo file, &man.vinum.8; crea la seguente
      struttura in <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>Benché sia raccomandato non allocare nomi specifici a plex e
      sottodischi, i drive di Vinum devono avere un nome.  Questo permette di
      spostare un disco in una differente locazione e continuare a riconoscerlo
      automaticamente.  I nomi di drive possono essere lunghi fino a 32
      caratteri.</para>

    <sect2>
      <title>Creare i File System</title>

      <para>I volumi appaiono al sistema identici ai dischi, con un'eccezione.
        Differentemente dai dischi &unix;, Vinum non partiziona i volumi,
        che quindi non contengono una tabella delle partizioni.  Questo ha reso
        necessario modificare alcuni programmi di utilità del disco, tra
        cui &man.newfs.8;, che precedentemente cercava di interpretare l'ultima
        lettera di un volume Vinum come un identificatore di partizione.
        Ad esempio un disco potrebbe avere un nome come
        <filename>/dev/ad0a</filename> o <filename>/dev/da2h</filename>.
        Questi nomi rappresentano la prima partizione
        (<devicename>a</devicename>) del primo (0) disco IDE
        (<devicename>ad</devicename>) e l'ottava partizione
        (<devicename>h</devicename>) del terzo (2) disco SCSI
        (<devicename>da</devicename>), rispettivamente.  Al contrario un volume
        Vinum potrebbe essere chiamato
        <filename>/dev/vinum/concat</filename>, un nome che non ha alcuna
        relazione con nomi di partizione.</para>

      <para>Normalmente &man.newfs.8; interpreta il nome del disco e si lamenta
        se non riesce a comprenderlo.  Per esempio:</para>

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

      <note><para>Queste informazioni sono valide solo per versioni di FreeBSD
        precedenti alla 5.0:</para></note>

      <para>Per poter creare un file system su questo volume usa &man.newfs.8;
        con l'opzione <option>-v</option>:</para>

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

  <sect1 id="vinum-config">
    <title>Configurare Vinum</title>

    <para>Il kernel <filename>GENERIC</filename> non contiene Vinum.
      È possibile creare un kernel speciale che lo contenga, ma questo
      non è raccomandato: il metodo standard per lanciare Vinum è
      come modulo del kernel (<acronym>kld</acronym>).  Non è neanche
      necessario usare &man.kldload.8; per Vinum: quando lanci &man.vinum.8; il
      programma controlla se il modulo è stato caricato e, in caso non
      sia caricato, lo carica automaticamente.</para>

    <sect2>
      <title>Avvio</title>

      <para>Vinum immagazzina le informazioni sulla configurazione dei dischi
        essenzialmente nella stessa forma dei file di configurazione.  Quando
        legge il database di configurazione Vinum riconosce un numero di
        parole chiave che non sono permesse nei file di configurazione, ad
        esempio un file di configurazione del disco potrebbe contenere il
        seguente testo:</para>

      <programlisting width="119">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>Le ovvie differenze sono qua la presenza di informazioni esplicite
        sulle locazioni e sulla nomenclatura (entrambe permesse, ma scoraggiate,
        all'utente) e le informazioni sugli stati (che non sono disponibili
        all'utente).  Vinum non immagazzina informazioni sui drive tra le
        informazioni della configurazione: trova i drive scandendo le partizioni
        dei dischi configurati alla ricerca di un'etichetta Vinum.  Questo
        permette a Vinum di identificare i drive correttamente anche se gli
        è stato assegnato un differente codice identificativo di drive
        &unix;.</para>

      <sect3 id="vinum-rc-startup">
        <title>Avvio Automatico</title>

        <para>Per poter lanciare Vinum automaticamente all'avvio del sistema
          assicuratevi che le seguenti linee siano nel vostro
          <filename>/etc/rc.conf</filename>:</para>

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

        <para>Se non hai un file <filename>/etc/rc.conf</filename>, creane uno
          con questo contenuto.  Questo ordinerà al sistema di caricare
          il Vinum <acronym>kld</acronym> all'avvio, inizializzando ogni oggetto
          menzionato nella configurazione.  Questo viene fatto prima del mount
          dei file system quindi è possibile fare automaticamente
          &man.fsck.8; e mount dei file system su volumi Vinum.</para>

        <para>Quando esegui Vinum con il comando <command>vinum start</command>
          Vinum legge il database di configurazione da uno dei drive Vinum.  In
          circostanze normali ogni drive contiene una copia identica del
          database di configurazione quindi non conta da quale disco viene
          letto.  Dopo un crash, tuttavia, Vinum deve determinare quale drive
          è stato aggiornato più recentemente e leggere la
          configurazione da questo drive.  Quindi aggiorna la configurazione, se
          necessario, sui drive progressivamente più vecchi.</para>
      </sect3>
    </sect2>
  </sect1>

  <sect1 id="vinum-root">
    <title>Usare Vinum nel Filesystem Root</title>

    <para>Per una macchina con filesystem completamente in mirroring con Vinum
      è desiderabile mettere in mirroring anche il filesystem di root;
      fare questo è meno semplice che non per un filesystem arbitrario,
      dato che:</para>

    <itemizedlist>
      <listitem>
        <para>Il filesystem root deve essere disponibile nella parte iniziale
          del processo di boot, quindi l'infrastruttura di Vinum deve essere
          già disponibile in quel momento.</para>
      </listitem>

      <listitem>
        <para>Il volume contenente il filesystem root contiene anche il sistema
          di avvio e il kernel, che devono essere letti usando le funzioni
          native del sistema (ovvero il BIOS, sui PC) che spesso non conoscono i
          dettagli di Vinum.</para>
      </listitem>
    </itemizedlist>

    <para>Nelle sezioni seguenti, il termine <quote>volume root</quote>
      è usato generalmente per descrivere il volume Vinum che contiene il
      filesystem root.  È probabilmente una buona idea usare il nome
      <literal>"root"</literal> per questo volume, ma non è necessario.
      Tutti gli esempi nelle prossime sezioni usano questo nome.</para>

    <sect2>
      <title>Lanciare Vinum abbastanza presto per il Filesystem Root</title>

      <para>Ci sono varie misure da prendere per fare in modo che questo
        accada:</para>

      <itemizedlist>
        <listitem>
          <para>Vinum deve essere disponibile nel kernel già all'avvio,
            quindi il metodo per lanciare Vinum automaticamente descritto
            in <xref linkend="vinum-rc-startup"/> non può essere
            utilizzato e il parametro <literal>start_vinum</literal> in
            realtà <emphasis>non</emphasis> va impostato in questo tipo
            di configurazione.  La prima possibilità è di
            compilare Vinum staticamente dentro al kernel, in modo che sia
            sempre disponibile, ma questo non è normalmente desiderabile.
            Un'altra opportunità à di fare in modo che
            <filename>/boot/loader</filename> (<xref
            linkend="boot-loader"/>) carichi il modulo kernel di Vinum prima di
            lanciare il kernel.  Questo può essere fatto utilizzando la
            riga:</para>

          <programlisting>vinum_load="YES"</programlisting>

          <para>nel file <filename>/boot/loader.conf</filename>.</para>
        </listitem>

        <listitem>
          <para>Vinum deve essere inizializzato subito in modo da poter fornire
            il volume per il filesystem root.  Per default la porzione kernel di
            Vinum non cerca dischi che contengano informazioni sui volumi Vinum
            fino a quando un amministratore (o uno degli script di partenza) non
            esegue un comando di <command>vinum start</command>.</para>

          <note>
            <para>I seguenti paragrafi spiegano i passi necessari per
              &os;&nbsp;5.X e superiori.  L'impostazione richiesta da
              &os;&nbsp;4.X è diversa ed è descritta dopo, in
              <xref linkend="vinum-root-4x"/>.</para>
          </note>

          <para>Inserendo la linea:</para>

          <programlisting>vinum.autostart="YES"</programlisting>

          <para>dentro a <filename>/boot/loader.conf</filename>, Vinum viene
            istruito, alla partenza del kernel, di controllare automaticamente
            tutti i dischi alla ricerca di informazioni sui volumi Vinum.</para>

          <para>Da notare il fatto che non è necessario istruire il
            kernel sulla locazione del filesystem root.
            <filename>/boot/loader</filename> cerca il nome del device di root
            in <filename>/etc/fstab</filename> e passa l'informazione al kernel.
            Quando è necessario montare il filesystem root, il kernel,
            tramite il nome di device fornitogli, capisce a quale driver deve
            chiedere la conversione di tale nome in ID interno di device (numero
            maggiore/minore).</para>
        </listitem>
      </itemizedlist>
    </sect2>

    <sect2>
      <title>Rendere un volume di root basato su Vinum accessibile
        dall'avvio</title>

      <para>Dato che il codice di avvio di FreeBSD è attualmente di soli
        7.5 KB ed è già appesantito dalla lettura di file (come
        <filename>/boot/loader</filename>) da un filesystem UFS, è
        semplicemente impossibile insegnargli anche a leggere le strutture
        interne di Vinum in modo da fargli leggere i dati della configurazione
        di Vinum per ricavarne gli elementi del volume di boot stesso.
        Sono quindi necessari alcuni trucchi per dare al codice di avvio
        l'illusione di una partizione <literal>"a"</literal> standard contenente
        il filesystem di root.</para>

      <para>Perché questo sia anche solo possibile, il volume di root
        deve rispondere ai seguenti requisiti:</para>

      <itemizedlist>
        <listitem>
          <para>Il volume di root non deve essere in striping o in RAID-5.</para>
        </listitem>

        <listitem>
          <para>Il volume di root non deve contenere la concatenazione di più di
            un sottodisco per ogni plex.</para>
        </listitem>
      </itemizedlist>

      <para>Da notare che è desiderabile e possibile avere plex multipli,
        contenente ognuno una replica del filesystem root.  Il processo di
        avvio, però, usa solo una di queste repliche per trovare i file
        necessario all'avvio, fino a quando il kernel monta il filesystem di
        root stesso.  Ogni singolo sottodisco in questi plex avrà quindi
        bisogno di una propria partizione <literal>"a"</literal> illusoria,
        affinché la periferica relativa possa essere avviabile.  Non
        è strettamente necessario che ognuna di queste finte partizioni
        <literal>"a"</literal> sia locato con lo stesso spiazzamento all'interno
        della propria periferica, rispetto alle periferiche contenenti gli altri
        plex del volume.  È comunque probabilmente una buona idea creare
        i volumi Vinum in modo che le periferiche in mirror siano simmetriche,
        per evitare confusione.</para>

      <para>Per poter configurare queste partizioni <literal>"a"</literal>,
        in ogni periferica contenente parte del volume di root, bisogna fare le
        seguenti cose:</para>

      <procedure>
        <step>
          <para>La locazione (spiazzamento dall'inizio della periferica) e la
            dimensione del sottodisco che è parte del volume di root deve
            essere esaminato, usando il comando:</para>

          <screen>&prompt.root; <userinput>vinum l -rv root</userinput></screen>

          <para>Da notare che gli spiazzamenti e le dimensioni in Vinum sono
            misurati in byte.  Devono essere divisi per 512 per ottenere il
            numero di blocchi necessari nel comando
            <command>disklabel</command>.</para> </step>

        <step>
          <para>Esegui il comando:</para>

          <screen>&prompt.root; <userinput>disklabel -e <replaceable>devname</replaceable></userinput></screen>

          <para>per ogni periferica che partecipa al volume di root.
            <replaceable>devname</replaceable> deve essere o il nome della slice
            (ad esempio <devicename>ad0s1</devicename>) o il nome del disco (ad
            esempio <devicename>da0</devicename>) per dischi senza tabella delle
            slice (ovvero i nomi che si usano anche con fdisk).</para>

          <para>Se c'è già una partizione <literal>"a"</literal>
            sulla periferica (presumibilmente contenente un filesystem root
            precedente all'uso di Vinum), dovrebbe essere rinominata in altro
            modo, in modo da restare accessibile (non si sa mai), ma non essere
            usata più per default per avviare il sistema.  Da notare che
            le partizioni attive (ad esempio un filesystem root attualmente
            montato) non possono essere rinominati, quindi questo deve essere
            eseguito o avviando da un disco <quote>Fixit</quote> o (in caso di
            mirror) in un processo a due passi dove il disco non di avvio viene
            modificato per primo.</para>

          <para>Infine, lo spiazzamento della partizione Vinum sulla periferica
            va aggiunto allo spiazzamento del rispettivo sottodisco di root
            rispetto alla periferica stessa. Il risultato sarà il valore
            di <literal>"offset"</literal> (spiazzamento) per la nuova
            partizione <literal>"a"</literal>.  Il valore
            <literal>"size"</literal> (dimensione) per questa partizione
            può essere copiato pari pari dal calcolo fatto sopra.
            Il valore <literal>"fstype"</literal> deve essere
            <literal>4.2BSD</literal>.  I valori <literal>"fsize"</literal>,
            <literal>"bsize"</literal> e <literal>"cpg"</literal> devono
            preferibilmente essere scelti per corrispondere al vero e proprio
            filesystem, anche se in questo contesto non sono molto
            importanti.</para>

          <para>In questo modo una nuova partizione <literal>"a"</literal>
            sarà creata ricoprendo le partizioni Vinum su questa
            periferica.  Da notare che <command>disklabel</command>
            permetterà questa ricopertura solo se la partizione Vinum
            è stata appropriatamente marcata usando un
            <literal>"fstype"</literal> pari a <literal>"vinum"</literal>
            fstype.</para> </step>

        <step>
          <para>È tutto!  Ora una falsa partizione <literal>"a"</literal>
            esiste su ogni periferica che abbia una replica del volume di root.
            È altamente raccomandabile verificare nuovamente i risultati,
            usando un comando come:</para>

          <screen>&prompt.root; <userinput>fsck -n /dev/<replaceable>devname</replaceable>a</userinput></screen>
        </step>
      </procedure>

      <para>Bisogna ricordarsi che tutte le informazioni contenute nei file di
        controllo devono essere relative al filesystem di root nel volume Vinum
        che, quando si imposta un nuovo volume di root Vinum, potrebbe non
        coincidere con quello del filesystem root attualmente attivo.
        In particolare bisogna stare attenti ai file
        <filename>/etc/fstab</filename> e
        <filename>/boot/loader.conf</filename>.</para>

      <para>Al seguente riavvio il sistema dovrebbe ricavare le informazioni di
        controllo appropriate dal filesystem di root Vinum e agire di
        consequenza.  Alla fine del processo di inizializzazione del kernel,
        dopo che tutte le periferiche sono state annunciate, l'avvertimento
        principale che conferma il successo dell'avvio è un messaggio
        simile a questo:</para>

      <screen>Mounting root from ufs:/dev/vinum/root</screen>
    </sect2>

    <sect2>
      <title>Esempi di configurazioni con root basata su Vinum</title>

      <para>Dopo aver creato il volume di root Vinum,
        <command>vinum l -rv root</command> dovrebbe produrre qualcosa di simile
        a:</para>

      <screen>
...
Subdisk root.p0.s0:
                Size:        125829120 bytes (120 MB)
                State: up
                Plex root.p0 at offset 0 (0  B)
                Drive disk0 (/dev/da0h) at offset 135680 (132 kB)

Subdisk root.p1.s0:
                Size:        125829120 bytes (120 MB)
                State: up
                Plex root.p1 at offset 0 (0  B)
                Drive disk1 (/dev/da1h) at offset 135680 (132 kB)
      </screen>

      <para>I valori su cui fare caso sono il <literal>135680</literal> dello
        spiazzamento (relativo alla partizione
        <filename>/dev/da0h</filename>). Questo si traduce in 265 blocchi da
        512 byte nei termini di <command>disklabel</command>.
        <filename>/dev/da1h</filename>, contenente la seconda replica del
        volume di root, ha una configurazione simmetrica.</para>

      <para>La <command>disklabel</command> per queste periferiche dovrebbe
        essere simile a questa:</para>

      <screen>
...
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:   245760      281    4.2BSD     2048 16384     0   # (Cyl.    0*- 15*)
  c: 71771688        0    unused        0     0         # (Cyl.    0 - 4467*)
  h: 71771672       16     vinum                        # (Cyl.    0*- 4467*)
      </screen>

      <para>Si può notare che il parametro <literal>"size"</literal> per
        la finta partizione <literal>"a"</literal> corrisponde al valore di cui
        abbiamo parlato prima, mentre il parametro <literal>"offset"</literal>
        è la somma dello spiazzamento all'interno della partizione Vinum
        <literal>"h"</literal> e lo spiazzamento all'interno della periferica (o
        slice).  Questa è una tipica configurazione necessaria per
        evitare il problema descritto in <xref linkend="vinum-root-panic"/>.
        Si può anche notare che l'intera partizione
        <literal>"a"</literal> è completamente contenuta dalla partizione
        <literal>"h"</literal>, che contiene tutti i dati Vinum per questa
        periferica.</para>

      <para>Notate che in questo esempio l'intera periferica è dedicata a
        Vinum e non c'è spazio per partizioni pre-Vinum, dato che questo
        disco è stato configurato da nuovo per il solo scopo di far parte
        di una configurazione Vinum.</para>
    </sect2>

    <sect2>
      <title>Risoluzione Problemi</title>

      <para>Se qualcosa va storto, serve un modo per tornare in una situazione
        di normalità.  Segue una lista di alcuni tipici problemi,
        completi di soluzione.</para>

      <sect3>
        <title>Il Codice di Avvio si Carica, ma il Sistema non si Avvia</title>

        <para>Se per qualsiasi ragione in sistema non prosegue nell'avvio, si
          può interrompere il processo di avvio premendo il tasto
          <keycap>spazio</keycap> all'avviso dei 10 secondi.  Le variabili di
          avvio potranno quindi essere esaminate usando il comando
          <command>show</command> e manipolate con <command>set</command> e
          <command>unset</command>.</para>

        <para>Se l'unico problema è che il modulo kernel di Vinum non
          è ancora presente nella lista dei moduli da caricare
          automaticamente, un semplice <command>load vinum</command>
          aiuterà.</para>

        <para>Quando pronti, il processo di avvio può continuare con un
          <command>boot -as</command>.  Le opzioni <option>-as</option>
          comunicano al kernel di montare il filesystem di root
          (<option>-a</option>) e di interrompere il processo di avvio in
          modalità singolo utente (<option>-s</option>),
          quando il filesystem di root è montato a sola lettura.  In
          questo modo benché uno solo dei plex do un volume multi-plex
          sia stato montato, non si rischia inconsistenza dei dati tra i vari
          plex.</para>

        <para>Alla richiesta di un filesystem di root da montare, ogni
          periferica che contenga un filesystem di root valido può essere
          usata. Se <filename>/etc/fstab</filename> è stato impostato
          correttamente, il default dovrebbe essere
          <literal>ufs:/dev/vinum/root</literal> o simile.  Una tipica
          alternativa potrebbe essere <literal>ufs:da0d</literal>, una
          ipotetica partizione contenente un filesystem root pre-Vinum.
          Bisogna fare attenzione quando si sceglie una delle partizioni
          <literal>"a"</literal> alias di un sottodisco della periferica root di
          Vinum, perché in una configurazione in mirror questo monterebbe
          solo un pezzo della root in mirror.  Se questo filesystem deve poi
          essere montato in lettura/scrittura è necessario rimuovere gli
          altri plex del volume root di Vinum dato che conterrebbero comunque
          dati non consistenti.</para>
      </sect3>

      <sect3>
        <title>Si Carica Solo l'Avvio Primario</title>

        <para>Se <filename>/boot/loader</filename> non si carica, ma l'avvio
          primario si carica comunque (si capisce dal singolo trattino nella
          colonna di sinistra dello schermo subito dopo l'inizio dell'avvio), si
          può tentare di fermare l'avvio primario in questo punto,
          premendo il tasto <keycap>spazio</keycap>.  Questo fermerà
          l'avvio nella seconda fase, vedi <xref linkend="boot-boot1"/>.  Qua si
          può fare un tentativo di caricare una differente partizione, ad
          esempio la partizione contenente il precedente filesystem di root
          <literal>"a"</literal>, prima di sostituirlo come sopra
          indicato.</para>
      </sect3>

      <sect3 id="vinum-root-panic">
        <title>Non si Carica Niente, l'Avvio va in Panico</title>

        <para>Questa situazione accade quando l'installazione di Vinum ha
          distrutto il codice di avvio.  Sfortunatamente Vinum lascia solo 4 KB
          liberi all'inizio della sua partizione prima di scrivere il proprio
          header.  Purtroppo le due fasi dell'avvio e la disklabel compresa tra
          le due attualmente occupa 8 KB, quindi se la partizione Vinum è
          creata con spiazzamento 0 in una slice o disco che dovrebbe essere
          avviabile, la configurazione di Vinum distruggerà il codice di
          avvio.</para>

        <para>Similmente, se la situazione sopra descritta è stata
          risolta avviando da un disco di <quote>Fixit</quote>, e il codice di
          avvio re-installato usando <command>disklabel -B</command> come
          descritto in <xref linkend="boot-boot1"/>, il codice di avvio
          distruggerà l'header di Vinum, che non saprà più
          trovare i propri dischi.  Benché nessun dato, di configurazione
          o contenuto, sia distrutto da questo processo, che risulta quindi
          recuperabile reinserendo la stessa configurazione di Vinum, la
          situazione è in realtà di difficile risoluzione: sarebbe
          necessario spostare l'intera partizione Vinum di almeno 4 KB, in modo
          da lasciare abbastanza spazio sia per il codice di avvio che per
          l'header Vinum.</para>
      </sect3>
    </sect2>

    <sect2 id="vinum-root-4x">
      <title>Differenze per FreeBSD 4.X</title>

      <para>In FreeBSD 4.X alcune funzioni interne necessarie a Vinum per poter
        trovare automaticamente tutti i dischi non sono presenti e il codice che
        ricava l'ID interno della periferica di root non è abbastanza
        intelligente da gestire automaticamente nomi come
        <filename>/dev/vinum/root</filename>, quindi le cose vengono fatte
        in modo un po' diverso.</para>

      <para>Bisogna dire esplicitamente a Vinum quali dischi controllare, usando
        una riga di <filename>/boot/loader.conf</filename> come la
        seguente:</para>

      <programlisting>vinum.drives="/dev/<replaceable>da0</replaceable> /dev/<replaceable>da1</replaceable>"</programlisting>

      <para>È importante indicare tutti i drive che possono contenere
        dati Vinum.  Non è un problema indicare drive <emphasis>di
        troppo</emphasis>, non è neanche necessario aggiungere
        esplicitamente ogni slice e/o partizione, dato che Vinum
        cercherà header Vinum in tutte le slice e partizioni dei drive
        nominati.</para>

      <para>Dato che le procedure utilizzate per interpretare il nome del
        filesystem di root e derivarne l'ID di periferica (numeri
        maggiore e minore) sono adatte per gestire solo nomi
        <quote>classici</quote> di periferica come
        <filename>/dev/ad0s1a</filename>, non riescono a capire nomi di
        volumi root come <filename>/dev/vinum/root</filename>.  Per questo
        motivo Vinum ha bisogno di pre-impostare durante la propria
        inzializzazione il parametro kernel interno che contiene l'ID della
        periferica di root.  Questo viene fatto indicando il nome del
        volume di root nella variabile di avvio <literal>vinum.root</literal>.
        La riga di <filename>/boot/loader.conf</filename> adatta per fare questo
        è simile alla seguente:</para>

      <programlisting>vinum.root="root"</programlisting>

      <para>Quando l'inizializzazione del kernel cerca di trovare la periferica
        root da montare controlla se qualche modulo del kernel ha già
        pre-inizializzato il parametro kernel apposito; se questo è il
        caso <emphasis>e</emphasis> la periferica che dice di essere la
        periferica di root ha il numero maggiore e minore corrispondenti al
        driver come trovato dal nome della periferica di root passata (ovvero
        <literal>"vinum"</literal>, nel nostro caso), userà l'ID di
        periferica pre-allocato, anziché cercar di trovarne uno da solo.
        In tal modo durante l'usuale avvio automatico può continuare a
        montare il volume di root Vinum per il filesystem di root.</para>

      <para>Bisogna comunque notare che anche quando <command>boot -a</command>
        richiede di inserire manualmente il nome della periferica di root tale
        nome non può essere intepretato nel caso sia un nome riferito a
        un volume Vinum.  Se è inserito un nome di periferica non
        riferito a una periferica Vinum, la non corrispondenza col numero
        maggiore pre-allocato del parametro di root e del driver ricavato dal
        nome farà sì che la procedura utilizzi il normale
        interprete, quindi una stringa come <literal>ufs:da0d</literal>
        funzionerà come previsto.  Da notare che se questo fallisce non
        si può più provare una stringa come
        <literal>ufs:vinum/root</literal>, dato che non verrebbe
        interpretata; l'unica via di uscita è riavviare e ripartire da
        zero.  (Alla richiesta di <quote>askroot</quote>, la parte iniziale
        <filename>/dev/</filename> può sempre essere omessa.)</para>
    </sect2>
  </sect1>
</chapter>