Greg Lehey Originariamente scritto da Qualunque siano i dischi che hai, ci sono sempre dei problemi potenziali: Potrebbero essere troppo piccoli. Potrebbero essere troppo lenti. Potrebbero essere troppo inaffidabili. Un modo in cui alcuni utenti salvaguardano sè stessi contro questi problemi è attraverso l'uso di dischi multipli, e talvolta ridondanti. 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. 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. Questo capitolo fornisce una panoramica sui potenziali problemi dell'archiviazione su disco tradizionale e un'introduzione al gestore di volumi Vinum. Vinum RAID software Vinum è un Volume Manager, 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. 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. 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 Mbit/s verso il mondo esterno, ben oltre il transfer rate (velocità di trasferimento) che la maggior parte dei dischi può sostenere. I dischi odierni possono trasferire sequenzialmente dati fino a 70 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. 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. Considera un tipico trasferimento di circa 10 kB: l'attuale generazione di dischi ad alte prestazioni può posizionare le testine in circa 3,5 ms. I dischi più veloci ruotano a 15.000 rpm, quindi la latenza media rotazionale (mezzo giro) è di 2 ms. A 70 MB/s, il trasferimento in sé occupa circa 150 μs, quasi nulla in confronto al tempo di posizionamento. In questo caso il transfer rate effettivo può scendere fino a poco oltre 1 MB/s e questo è chiaramente molto dipendente dalla dimensione del trasferimento. La tradizionale e ovvia soluzione a questo collo di bottiglia è più assi: 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. 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. concatenazione dei dischi Vinum concatenazione 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 concatenazione 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 illustra la sequenza in cui le unità di immagazzinamento sono allocate nell'organizzazione concatenata.

striping dei dischi Vinum striping RAID RAID livello 0 RAID-0 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 striping (letteralmente "a bande") o RAID-0 RAID significa Redundant Array of Inexpensive Disks (insieme ridondante di dischi non costosi) e offre varie forme di tolleranza ai problemi. Nel caso del RAID-0 il termine è leggermente fuorviante: in effetti non dà alcuna ridondanza. . 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 illustra la sequenza in cui i blocchi di dati sono allocati nell'organizzazione in striping.

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. mirroring dei dischi Vinum mirroring RAID livello 1 RAID-1 Il metodo tradizionale per affrontare questo problema si chiama mirroring (letteralmente "specchiatura") e consiste nel tenere due copie dei dati su hardware fisici differenti. Con l'avvento dei livelli RAID questa tecnica è stata chiamata RAID di livello 1 o RAID-1. 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. Il mirroring ha due problemi: Il prezzo. Richiede il doppio dello spazio di immagazzinamento delle soluzioni non ridondanti. 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. Vinum striping con parità RAID-5 Una soluzione alternativa è la parità, implementata nel RAID di livello 2, 3, 4 e 5. Di questi, il RAID-5 è 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 RAID-5 è simile a un blocco in striping, con la differenza che implementa il RAID-5 includendo un blocco di parità per ogni banda. Come richiesto dal RAID-5 la locazione di questi blocchi di parità cambia da ogni banda alla successiva. I numeri nei blocchi dati indicano il numero dei blocchi relativi.

Comparandolo al mirroring, il RAID-5 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. Per risolvere questi problemi Vinum implementa una categoria di oggetti a quattro livelli: L'oggetto più visibile è il disco virtuale, chiamato volume. I volumi hanno essenzialmente le stesse proprietà di un disco &unix;, benché ci sia qualche differenza minore. Non hanno limiti di dimensione. I volumi sono composti da plex, 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. 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; (drive, ovvero dischi) in aree contigue chiamate subdisks (sottodischi), che sono a loro volta utilizzati come elementi per costruire i plex. I sottodischi risiedono su drive 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. La sezione seguente descrive come gli oggetti sopra discussi possano dare le funzionalità richieste. 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. 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. 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. Vinum implementa sia la concatenazione che lo striping al livello di plex: Un plex concatenato usa lo spazio di indirizzamento di ogni sottodisco a turno. Un plex in striping 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. La versione di Vinum distribuita con FreeBSD &rel.current; implementa due tipi di plex: 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 CPU di un plex in striping, benché la differenza in carico di CPU non sia misurabile. D'altro canto sono più suscettibili agli hot spot (letteralmente zona calda): ovvero situazioni in cui un disco è molto attivo mentre gli altri sono fermi. Il più grande vantaggio dei plex in striping (RAID-0) è la loro capacità di ridurre gli hot spot: scegliendo una dimensione di striping ottimale (circa 256 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. La riassume vantaggi e svantaggi di ogni tipo di organizzazione dei plex. Tipo di plex Sottodischi minimi Sottodischi aggiungibili Dimensioni forzatamente uguali Applicazione concatenato 1 sì no Immagazzinamento di grandi moli di dati con la massima flessibilità e prestazioni moderate striping 2 no sì Alte prestazioni in casi di accessi altamente concorrenti Vinum mantiene un database della configurazione 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 device, ovvero dispositivo) 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. Il file di configurazione descrive singoli oggetti Vinum. La definizione di un semplice volume potrebbe essere: drive a device /dev/da3h volume myvol plex org concat sd length 512m drive a Questo file descrive quattro oggetti Vinum: La linea drive descrive la partizione del disco (drive) e la sua locazione relativa all'hardware sottostante. Gli viene assegnato il nome simbolico a. Questa separazione dei nomi simbolici dai nomi di dispositivo permette di muovere i dischi da una locazione ad un'altra senza confusione. La linea volume descrive un volume. L'unico attributo richiesto è il nome, in questo caso myvol. La linea plex definisce un plex. L'unico parametro richiesto è il tipo di organizzazione, in questo caso concat. Non è necessario un nome: il sistema genera un nome automaticamente a partire dal nome del volume, aggiungendo un suffisso .px, dove x indica il numero del plex nel volume. Il plex verrà quindi chiamato myvol.p0. La linea sd 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 .sx, dove x indica il numero del sottodisco nel plex, quindi Vinum darà a questo sottodisco il nome di myvol.p0.s0. Dopo aver elaborato questo file, &man.vinum.8; produce il seguente output: &prompt.root; vinum -> create config1 Configuration summary Drives: 1 (4 configured) Volumes: 1 (4 configured) Plexes: 1 (8 configured) Subdisks: 1 (16 configured) D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB Questo output mostra il formato di elenco breve di &man.vinum.8;, che è rappresentato graficamente nella .

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. 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. 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: drive b device /dev/da4h volume mirror plex org concat sd length 512m drive a plex org concat sd length 512m drive b In questo esempio non è necessario specificare nuovamente la definizione del drive a, dato che Vinum mantiene traccia di tutti gli oggetti nel suo database di configurazione. Dopo aver elaborato questa definizione, la configurazione appare così: 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 mostra la struttura graficamente.

In questo esempio ogni plex contiene l'intero spazio di indirizzamento di 512 MB. Come nel precedente esempio ogni plex contiene un solo sottodisco. 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: 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 Come prima non è necessario definire i drive che Vinum già conosce. Dopo aver elaborato queste definizioni la configurazione appare così: 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

Questo volume è rappresentato nella . 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. 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: 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 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. La rappresenta la struttura di questo volume.

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. 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. /dev/vinum I nomi assegnati agli oggetti Vinum sono nella gerarchia /dev/vinum. La configurazione di Vinum mostrata sopra creerebbe i seguenti dispositivi: I dispositivi di controllo /dev/vinum/control e /dev/vinum/controld, utilizzati rispettivamente da &man.vinum.8; e dal demone Vinum. 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 r all'inizio del nome. Quindi la configurazione vista sopra genererebbe i dispositivi a blocchi /dev/vinum/myvol, /dev/vinum/mirror, /dev/vinum/striped, /dev/vinum/raid5 e /dev/vinum/raid10, e i dispositivi a caratteri /dev/vinum/rmyvol, /dev/vinum/rmirror, /dev/vinum/rstriped, /dev/vinum/rraid5 e /dev/vinum/rraid10. In questo c'è un ovvio problema: è possibile avere due volumi chiamati r e rr che avrebbero un conflitto nel creare il nodo /dev/vinum/rr: sarebbe il dispositivo a caratteri per il volume r o il dispositivo a blocchi per il volume rr? Attualmente Vinum non si interessa di questo conflitto: il volume definito per primo prende il nome. Una directory /dev/vinum/drive con voci per ogni disco. Queste voci sono in effetti dei collegamenti simbolici ai rispettivi nodi di disco. Una directory /dev/vinum/volume con voci per ogni volume. Contiene sottodirectory per ogni plex, che a loro volta contengono sottodirectory per ogni sottodisco. Le directory /dev/vinum/plex, /dev/vinum/sd e /dev/vinum/rsd contengono i dispositivi a blocchi per ogni plex, dispositivo a blocchi e dispositivo a caratteri per ogni sottodisco rispettivamente. Ad esempio, considera il seguente file di configurazione: 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 Dopo aver elaborato questo file, &man.vinum.8; crea la seguente struttura in /dev/vinum: brwx------ 1 root wheel 25, 0x40000001 Apr 13 16:46 Control brwx------ 1 root wheel 25, 0x40000002 Apr 13 16:46 control brwx------ 1 root wheel 25, 0x40000000 Apr 13 16:46 controld drwxr-xr-x 2 root wheel 512 Apr 13 16:46 drive drwxr-xr-x 2 root wheel 512 Apr 13 16:46 plex crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 rs64 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 rsd drwxr-xr-x 2 root wheel 512 Apr 13 16:46 rvol brwxr-xr-- 1 root wheel 25, 2 Apr 13 16:46 s64 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd drwxr-xr-x 3 root wheel 512 Apr 13 16:46 vol /dev/vinum/drive: total 0 lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive1 -> /dev/sd1h lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive2 -> /dev/sd2h lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive3 -> /dev/sd3h lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive4 -> /dev/sd4h /dev/vinum/plex: total 0 brwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 /dev/vinum/rsd: total 0 crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0 crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1 crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2 crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3 /dev/vinum/rvol: total 0 crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64 /dev/vinum/sd: total 0 brwxr-xr-- 1 root wheel 25, 0x20000002 Apr 13 16:46 s64.p0.s0 brwxr-xr-- 1 root wheel 25, 0x20100002 Apr 13 16:46 s64.p0.s1 brwxr-xr-- 1 root wheel 25, 0x20200002 Apr 13 16:46 s64.p0.s2 brwxr-xr-- 1 root wheel 25, 0x20300002 Apr 13 16:46 s64.p0.s3 /dev/vinum/vol: total 1 brwxr-xr-- 1 root wheel 25, 2 Apr 13 16:46 s64 drwxr-xr-x 3 root wheel 512 Apr 13 16:46 s64.plex /dev/vinum/vol/s64.plex: total 1 brwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 s64.p0.sd /dev/vinum/vol/s64.plex/s64.p0.sd: total 0 brwxr-xr-- 1 root wheel 25, 0x20000002 Apr 13 16:46 s64.p0.s0 brwxr-xr-- 1 root wheel 25, 0x20100002 Apr 13 16:46 s64.p0.s1 brwxr-xr-- 1 root wheel 25, 0x20200002 Apr 13 16:46 s64.p0.s2 brwxr-xr-- 1 root wheel 25, 0x20300002 Apr 13 16:46 s64.p0.s3 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. 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 /dev/ad0a o /dev/da2h. Questi nomi rappresentano la prima partizione (a) del primo (0) disco IDE (ad) e l'ottava partizione (h) del terzo (2) disco SCSI (da), rispettivamente. Al contrario un volume Vinum potrebbe essere chiamato /dev/vinum/concat, un nome che non ha alcuna relazione con nomi di partizione. Normalmente &man.newfs.8; interpreta il nome del disco e si lamenta se non riesce a comprenderlo. Per esempio: &prompt.root; newfs /dev/vinum/concat newfs: /dev/vinum/concat: can't figure out file system partition Queste informazioni sono valide solo per versioni di FreeBSD precedenti alla 5.0: Per poter creare un file system su questo volume usa &man.newfs.8; con l'opzione -v: &prompt.root; newfs -v /dev/vinum/concat Il kernel GENERIC 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 (kld). 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. 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: 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 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;. Per poter lanciare Vinum automaticamente all'avvio del sistema assicuratevi che le seguenti linee siano nel vostro /etc/rc.conf: start_vinum="YES" # set to YES to start vinum Se non hai un file /etc/rc.conf, creane uno con questo contenuto. Questo ordinerà al sistema di caricare il Vinum kld 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. Quando esegui Vinum con il comando vinum start 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. 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: 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. 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. Nelle sezioni seguenti, il termine volume root è usato generalmente per descrivere il volume Vinum che contiene il filesystem root. È probabilmente una buona idea usare il nome "root" per questo volume, ma non è necessario. Tutti gli esempi nelle prossime sezioni usano questo nome. Ci sono varie misure da prendere per fare in modo che questo accada: Vinum deve essere disponibile nel kernel già all'avvio, quindi il metodo per lanciare Vinum automaticamente descritto in non può essere utilizzato e il parametro start_vinum in realtà non 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 /boot/loader () carichi il modulo kernel di Vinum prima di lanciare il kernel. Questo può essere fatto utilizzando la riga: vinum_load="YES" nel file /boot/loader.conf. 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 vinum start. I seguenti paragrafi spiegano i passi necessari per &os; 5.X e superiori. L'impostazione richiesta da &os; 4.X è diversa ed è descritta dopo, in . Inserendo la linea: vinum.autostart="YES" dentro a /boot/loader.conf, Vinum viene istruito, alla partenza del kernel, di controllare automaticamente tutti i dischi alla ricerca di informazioni sui volumi Vinum. Da notare il fatto che non è necessario istruire il kernel sulla locazione del filesystem root. /boot/loader cerca il nome del device di root in /etc/fstab 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). Dato che il codice di avvio di FreeBSD è attualmente di soli 7.5 KB ed è già appesantito dalla lettura di file (come /boot/loader) 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 "a" standard contenente il filesystem di root. Perché questo sia anche solo possibile, il volume di root deve rispondere ai seguenti requisiti: Il volume di root non deve essere in striping o in RAID-5. Il volume di root non deve contenere la concatenazione di più di un sottodisco per ogni plex. 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 "a" illusoria, affinché la periferica relativa possa essere avviabile. Non è strettamente necessario che ognuna di queste finte partizioni "a" 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. Per poter configurare queste partizioni "a", in ogni periferica contenente parte del volume di root, bisogna fare le seguenti cose: La locazione (spiazzamento dall'inizio della periferica) e la dimensione del sottodisco che è parte del volume di root deve essere esaminato, usando il comando: &prompt.root; vinum l -rv root 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 disklabel. Esegui il comando: &prompt.root; disklabel -e devname per ogni periferica che partecipa al volume di root. devname deve essere o il nome della slice (ad esempio ad0s1) o il nome del disco (ad esempio da0) per dischi senza tabella delle slice (ovvero i nomi che si usano anche con fdisk). Se c'è già una partizione "a" 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 Fixit o (in caso di mirror) in un processo a due passi dove il disco non di avvio viene modificato per primo. 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 "offset" (spiazzamento) per la nuova partizione "a". Il valore "size" (dimensione) per questa partizione può essere copiato pari pari dal calcolo fatto sopra. Il valore "fstype" deve essere 4.2BSD. I valori "fsize", "bsize" e "cpg" devono preferibilmente essere scelti per corrispondere al vero e proprio filesystem, anche se in questo contesto non sono molto importanti. In questo modo una nuova partizione "a" sarà creata ricoprendo le partizioni Vinum su questa periferica. Da notare che disklabel permetterà questa ricopertura solo se la partizione Vinum è stata appropriatamente marcata usando un "fstype" pari a "vinum" fstype. È tutto! Ora una falsa partizione "a" esiste su ogni periferica che abbia una replica del volume di root. È altamente raccomandabile verificare nuovamente i risultati, usando un comando come: &prompt.root; fsck -n /dev/devnamea 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 /etc/fstab e /boot/loader.conf. 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: Mounting root from ufs:/dev/vinum/root Dopo aver creato il volume di root Vinum, vinum l -rv root dovrebbe produrre qualcosa di simile a: ... 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) I valori su cui fare caso sono il 135680 dello spiazzamento (relativo alla partizione /dev/da0h). Questo si traduce in 265 blocchi da 512 byte nei termini di disklabel. /dev/da1h, contenente la seconda replica del volume di root, ha una configurazione simmetrica. La disklabel per queste periferiche dovrebbe essere simile a questa: ... 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*) Si può notare che il parametro "size" per la finta partizione "a" corrisponde al valore di cui abbiamo parlato prima, mentre il parametro "offset" è la somma dello spiazzamento all'interno della partizione Vinum "h" e lo spiazzamento all'interno della periferica (o slice). Questa è una tipica configurazione necessaria per evitare il problema descritto in . Si può anche notare che l'intera partizione "a" è completamente contenuta dalla partizione "h", che contiene tutti i dati Vinum per questa periferica. 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. Se qualcosa va storto, serve un modo per tornare in una situazione di normalità. Segue una lista di alcuni tipici problemi, completi di soluzione. Se per qualsiasi ragione in sistema non prosegue nell'avvio, si può interrompere il processo di avvio premendo il tasto spazio all'avviso dei 10 secondi. Le variabili di avvio potranno quindi essere esaminate usando il comando show e manipolate con set e unset. Se l'unico problema è che il modulo kernel di Vinum non è ancora presente nella lista dei moduli da caricare automaticamente, un semplice load vinum aiuterà. Quando pronti, il processo di avvio può continuare con un boot -as. Le opzioni -as comunicano al kernel di montare il filesystem di root (-a) e di interrompere il processo di avvio in modalità singolo utente (-s), 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. Alla richiesta di un filesystem di root da montare, ogni periferica che contenga un filesystem di root valido può essere usata. Se /etc/fstab è stato impostato correttamente, il default dovrebbe essere ufs:/dev/vinum/root o simile. Una tipica alternativa potrebbe essere ufs:da0d, una ipotetica partizione contenente un filesystem root pre-Vinum. Bisogna fare attenzione quando si sceglie una delle partizioni "a" 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. Se /boot/loader 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 spazio. Questo fermerà l'avvio nella seconda fase, vedi . Qua si può fare un tentativo di caricare una differente partizione, ad esempio la partizione contenente il precedente filesystem di root "a", prima di sostituirlo come sopra indicato. 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. Similmente, se la situazione sopra descritta è stata risolta avviando da un disco di Fixit, e il codice di avvio re-installato usando disklabel -B come descritto in , 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. 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 /dev/vinum/root, quindi le cose vengono fatte in modo un po' diverso. Bisogna dire esplicitamente a Vinum quali dischi controllare, usando una riga di /boot/loader.conf come la seguente: vinum.drives="/dev/da0 /dev/da1" È importante indicare tutti i drive che possono contenere dati Vinum. Non è un problema indicare drive di troppo, 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. 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 classici di periferica come /dev/ad0s1a, non riescono a capire nomi di volumi root come /dev/vinum/root. 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 vinum.root. La riga di /boot/loader.conf adatta per fare questo è simile alla seguente: vinum.root="root" 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 e 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 "vinum", 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. Bisogna comunque notare che anche quando boot -a 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 ufs:da0d funzionerà come previsto. Da notare che se questo fallisce non si può più provare una stringa come ufs:vinum/root, dato che non verrebbe interpretata; l'unica via di uscita è riavviare e ripartire da zero. (Alla richiesta di askroot, la parte iniziale /dev/ può sempre essere omessa.)