Terminiamo questa serie di articoli (parte 1, parte 2) sulla consistenza su disco di ZFS analizzando una comoda proprietà impostabile a livello di filesystem che ci consente di aumentare le probabilità di ripristino di un file in caso di errore anche avendo a disposizione un solo disco fisso. Purtroppo in molti casi ci è impossibile disporre di un secondo disco per impostare il mirroring a livello di pool; pensate ad esempio ai portatili, potrei aggiungere come secondo disco di mirror un disco esterno collegato via USB, ma le prestazioni ne risentirebbero!
Grazie alla proprietà copies, impostabile a livello di filesystem, possiamo indicare a ZFS quante copie deve fare di ogni singolo blocco dati, nel caso in cui uno di questi blocchi fosse danneggiato ZFS provvederà a recuperarlo dalla seconda copia così come avrebbe fatto da un secondo disco. Il limite massimo di copie impostabili è pari a tre.

ATTENZIONE: i test comportano l’alterazione dei dati presenti nei dischi utilizzati nei pool, quindi effettuate questi test su filesystem di prova, che non contengono dati e sopratutto A VOSTRO RISCHIO E PERICOLO!!!!

Andiamo a valutare il comportamento di ZFS in caso di alterazione del disco come visto negli altri esempi.
Cominciamo creando il nostro pool di test con un solo disco:

$ mkfile 150m disk1
$ pfexec zpool create testPool `pwd`/disk1

impostiamo a due il numero delle copie settando l’apposita opzione in fase di creazione del filesystem:

$ pfexec zfs create -o copies=2 testPool/fs1

copiamo il solito file di test e rileviamo l’Object-ID e il DVA del primo blocco dati:

$ pfexec cp /etc/bash/bash_completion /testPool/fs1/
$ ls -li /testPool/fs1/
total 1
5 -rwxr-xr-x 1 root root 217434 2009-12-16 11:37 bash_completion*
$ pfexec zdb -ddddd testPool/fs1 5
Dataset testPool/fs1 [ZPL], ID 30, cr_txg 6, 547K, 5 objects,
rootbp DVA[0]=<0:5c800:200> DVA[1]=<0:1c5c800:200> DVA[2]=<0:3814a00:200> [L0 DMU objset]
fletcher4 lzjb LE contiguous unique triple size=800L/200P
birth=10L/10P fill=5
cksum=155932587a:748a6697e34:1521b17e820db:2b3b6c4032fb3a

    Object  lvl   iblk   dblk  dsize  lsize   %full  type
         5    2    16K   128K   515K   256K  100.00  ZFS plain file
                                        264   bonus  ZFS znode
	dnode flags: USED_BYTES USERUSED_ACCOUNTED
	dnode maxblkid: 1
	path	/bash_completion
	uid     0
	gid     0
	atime	Wed Dec 16 11:37:03 2009
	mtime	Wed Dec 16 11:37:03 2009
	ctime	Wed Dec 16 11:37:03 2009
	crtime	Wed Dec 16 11:37:03 2009
	gen	10
	mode	100755
	size	217434
	parent	3
	links	1
	xattr	0
	rdev	0x0000000000000000
Indirect blocks:
               0 L1  0:5a000:400 4000L/400P F=2 B=10/10
               0  L0 0:19e00:20000 20000L/20000P F=1 B=10/10
           20000  L0 0:39e00:20000 20000L/20000P F=1 B=10/10

		segment [0000000000000000, 0000000000040000) size  256K

frammentiamo, sporchiamo e ricostruiamo il disco come al solito:

$ pfexec zpool export testPool
$ ./zsplit.sh disk1 0x19e00
8399+0 records in
8399+0 records out
4300288 bytes (4.3 MB) copied, 0.100184 s, 42.9 MB/s
256+0 records in
256+0 records out
131072 bytes (131 kB) copied, 0.00666101 s, 19.7 MB/s
298545+0 records in
298545+0 records out
152855040 bytes (153 MB) copied, 3.43945 s, 44.4 MB/s
$ head disk1-p2
#
# This file contains an example set of shell completions that can be used with
# bash(1).  These completions allow a user to complete filenames, commands
# name, command line options, and command line arguments using the [tab] key.
# The completions defined here are specific to the GNU command set, as a result
# they will provide the choice of GNU command line options in response to the
# [tab] key.  For the completed options to match the command implementation,
# you may have to have /usr/gnu/bin at the head of your PATH.
#
# These completions are not included in the default bash(1) environment.  To
$ sed "s/ file / FILE /g" disk1-p2 > disk1-p2-bad
$ cat disk1-p1 disk1-p2-bad disk1-p3 > disk1

ora non ci resta che accedere nuovamente al file e vedere come si comporta ZFS:

$ pfexec zpool import -d `pwd` testPool
$ zpool status testPool
  pool: testPool
 state: ONLINE
 scrub: none requested
config:

	NAME                                    STATE     READ WRITE CKSUM
	testPool                                ONLINE       0     0     0
	  /export/home/luca/itl-osug/zfs/disk1  ONLINE       0     0     0

errors: No known data errors
$ head /testPool/fs1/bash_completion
#
# This file contains an example set of shell completions that can be used with
# bash(1).  These completions allow a user to complete filenames, commands
# name, command line options, and command line arguments using the [tab] key.
# The completions defined here are specific to the GNU command set, as a result
# they will provide the choice of GNU command line options in response to the
# [tab] key.  For the completed options to match the command implementation,
# you may have to have /usr/gnu/bin at the head of your PATH.
#
# These completions are not included in the default bash(1) environment.  To
$ zpool status testPool
  pool: testPool
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
	attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
	using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://www.sun.com/msg/ZFS-8000-9P
 scrub: none requested
config:

	NAME                                    STATE     READ WRITE CKSUM
	testPool                                ONLINE       0     0     0
	  /export/home/luca/itl-osug/zfs/disk1  ONLINE       0     0     1

errors: No known data errors

benissimo, ZFS è riuscito a recuperare il contenuto del file dalla seconda copia e ci informa dell’accaduto, spetterà poi a noi valutare se è giunti il momento di sostituire il disco!
Ricordate che è possibile variare il numero di copie impostando l’apposita opzione:

$ pfexec zfs set copies=3 testPool/fs1

tuttavia il nuovo numero di copie riguarderà solo i nuovi file che verranno scritti o modificati dopo la modifica della proprietà.

Con l’uscita della build 128a di OpenSolaris viene aggiunta una nuova ed importante funzionalità a ZFS: la “deduplication” (evito di tradurre la parola…). Grazie a questa nuova funzionalità il filesystem è in grado di riconoscere eventuali blocchi duplicati e scriverli una volta solo… risparmiando così spazio su disco! I blocchi vengono riconosciuti grazie ad una chiave di hash generata da un algoritmo (selezionabile) e verificata prima di ogni scrittura.
Prima di entrare nel dettaglio mettiamo subito alla prova tale feature; creiamo tre dischi “su file” (da 150 Mega ciascuno) che andranno a comporre il nostro pool:

$ mkfile 150m disk1 disk2 disk3

ora creiamo il nuovo pool, chiamandolo con molta fantasia “dedup”:

$ pfexec zpool create dedup \
    /export/home/luca/tmp/disk1 \
    /export/home/luca/tmp/disk2 \
    /export/home/luca/tmp/disk3

controllandone le caratteristiche vediamo subito che la dimensione è pari a 435 Megabyte e notiamo che il rapporto di “deduplication” è pari a uno (visto che ancora non abbiamo scritto nulla):

$ zpool get all dedup
NAME   PROPERTY       VALUE       SOURCE
dedup  size           435M        -
dedup  capacity       0%          -
dedup  altroot        -           default
dedup  health         ONLINE      -
dedup  guid           598651376828683765  default
dedup  version        22          default
dedup  bootfs         -           default
dedup  delegation     on          default
dedup  autoreplace    off         default
dedup  cachefile      -           default
dedup  failmode       wait        default
dedup  listsnapshots  off         default
dedup  autoexpand     off         default
dedup  dedupratio     1.00x       -
dedup  free           435M        -
dedup  allocated      79.5K       -

ora andiamo ad abilitare la “deduplication” a livello di filesystem:

$ pfexec zfs set dedup=on dedup

da questo momento in poi, per ogni nuovo blocco che ZFS andrà a scrivere effettuerà il controllo di duplicazione: copiamo alcuni file nel nuovo filesystem e controlliamo. Per il test ho scelto di copiare alcuni MP3 presenti sul mio disco fisso, vediamo l’occupazione dei file prescelti:

$ du -h /export/home/luca/Documents/Music/aavv_80/
72M    /export/home/luca/Documents/Music/aavv_80/

ora creiamo tre cartelle nel nostro filesystem su cui andremo a copiare i file

$ cd /dedup
$ pfexec mkdir d1
$ pfexec mkdir d2
$ pfexec mkdir d3
$ pfexec mkdir d4

e copiamo i file:

$ pfexec cp /export/home/luca/Documents/Music/aavv_80/* d1
$ pfexec cp /export/home/luca/Documents/Music/aavv_80/* d2
$ pfexec cp /export/home/luca/Documents/Music/aavv_80/* d3
$ pfexec cp /export/home/luca/Documents/Music/aavv_80/* d4

ora controlliamo lo spazio occupato:

$ du -h .
72M    ./d1
72M    ./d2
72M    ./d3
72M    ./d4
287M    .

i conti tornano; su tutte e quattro le cartelle sono presenti 72 Megabyte di MP3… mmmm… e la “deduplication” che fine ha fatto… non ha funzionato?!?!??? Controlliamo meglio:

$ zpool list dedup
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
dedup   435M  72.5M   363M    16%  4.00x  ONLINE  -

ecco svelato il mistero!!! Il comando “du” (come anche ls e molti altri) agendo a livello user “vede” la dimensione reale del file (la stessa cosa accade per i filesystem compressi), ma se controlliamo meglio lo spazio allocato a livello di pool vediamo che in realtà sono stati utilizzati “solo” 72.5 Megabyte e il rapporto di “deduplication” è salito a 4; ora i conti tornano alla perfezione!!!

Bene, dopo la pratica torniamo a parlare di teoria, analizzando le varie opzioni legate a questa nuova caratteristica. In precedenza abbiamo semplicemente attivato la deduplication, accettando così le impostazioni di default, tuttavia esistono diverse opzioni settabili per la proprietà dedup:

• off: dedup disattivata;
• on: dedup attivata, il blocchi vengono controllati con l’algoritmo SHA256;
• verify: come sopra l’algoritmo di hash è sempre SHA256, ma in caso di rilevamento di un blocco uguale, viene verificata l’esattezza bit a bit;
• fletcher4,verify: viene usato l’algoritmo di hash “fletcher4″, che risulta essere molto più veloce ma che produce con maggiore probabilità delle duplicazioni di chiavi e quindi è per questo che la verifica è obbligatoria.

Non è detto che in futuro vengano implementati anche altri algoritmi per la verifica delle duplicazioni dei blocchi, il consiglio è quello di attivare la deduplication con l’opzione verify per stare tranquilli

Come già detto nei precedenti post inerenti ZFS è un filesystem “nato sicuro”, ovvero per sua natura abbiamo la massima garanzia di affidabilità per quello che riguarda le memorizzazioni su disco; tuttavia se veramente vogliamo dormire sonni tranquilli e sfruttare tutte le features di sicurezza di ZFS è consigliabile fornire più di un disco al sistema in modo che si possa quantomeno implementare un mirroring dei dati (sistema minimo di ridondanza).

Se al momento dell’installazione di OpenSolaris (o dell’ultima release di Solaris 10) avevate a disposizione un solo disco ZFS creerà in automatico un mirror “zoppo”, finchè non gli fornirete il secondo disco, se avete un disco nuovo nuovo basterà digitare:

# zpool attach -f rpool c0t0d0s0 c0t1d0s0

dove rpool è il nome del vostro pool, seguito dal device del vecchio disco e da quello del nuovo. Se invece il disco che andate ad aggiungere non è nuovo (magari proviene da una vecchia macchina o contiene una versione di Solaris che andate ad aggiornare) riceverete un bel messaggio di errore:

# zpool attach -f rpool c0t0d0s0 c0t1d0s0
cannot attach c0t1d0s0 to c0t0d0s0: device is too small

questo perchè con molta probabilità il vostro disco contiene già una label in formato EFI e questo tipo di label non “copre” totalmente la dimensione del disco, quindi occorrerà passare al formato SMI, per fare questo useremo il comando format (ho evidenziato in grassetto le scelte effettuate):

# format -e
Searching for disks...done

AVAILABLE DISK SELECTIONS:
       0. c0t0d0 <DEFAULT cyl 8921 alt 2 hd 255 sec 63>
          /pci@0,0/pci8086,25f8@4/pci1000,3150@0/sd@0,0
       1. c0t1d0 <DEFAULT cyl 8915 alt 2 hd 255 sec 63>
          /pci@0,0/pci8086,25f8@4/pci1000,3150@0/sd@1,0
Specify disk (enter its number): 1
selecting c0t1d0
[disk formatted]

FORMAT MENU:
        disk       - select a disk
        type       - select (define) a disk type
        partition  - select (define) a partition table
        current    - describe the current disk
        format     - format and analyze the disk
        fdisk      - run the fdisk program
        repair     - repair a defective sector
        label      - write label to the disk
        analyze    - surface analysis
        defect     - defect list management
        backup     - search for backup labels
        verify     - read and display labels
        save       - save new disk/partition definitions
        inquiry    - show vendor, product and revision
        scsi       - independent SCSI mode selects
        cache      - enable, disable or query SCSI disk cache
        volname    - set 8-character volume name
        !<cmd>     - execute <cmd>, then return
        quit
format> label
[0] SMI Label
[1] EFI Label
Specify Label type[0]: 0
Ready to label disk, continue? y

format> quit
#

fatto questo potremo ripetere il comando di attach e in automatico ZFS comincerà il resilvering del disco in modo da sincronizzare i dati.

# zpool status
  pool: rpool
 state: ONLINE
 scrub: resilver completed after 0h11m with 0 errors on Thu Apr 23 15:09:22 2009
config:

        NAME          STATE     READ WRITE CKSUM
        rpool         ONLINE       0     0     0
          mirror      ONLINE       0     0     0
            c0t0d0s0  ONLINE       0     0     0
            c0t1d0s0  ONLINE       0     0     0

errors: No known data errors

C’è da aggiungere una piccola nota, alcune volte è necessario cancellare tutte le vecchie partizioni presenti sul disco prima di cambiare il formato delle label, basta entrare nel sottomenu fdisk e rimuovere tutte le partizioni e poi ripetere le operazioni viste prima.

Finalmente è arrivato il mio primo contributo ad OpenSolaris!
Già da qualche giorno nella mia signature delle mail compariva la misteriosa nota “OpenSolaris SCA #OS0344“, dove SCA stà per Sun Contributor Agreement; ma questa mattina, grazie all’aiuto di Tim Foster, ho committato la mia prima patch sul sistema, che permetterà di utilizzare la proprietà offset nel servizio zfs-auto-snapshot.
Ancora un grazie a Tim per il supporto e i preziosi consigli!!

Qui potete leggere l’annuncio del commit in mailing list:
http://mail.opensolaris.org/pipermail/zfs-auto-snapshot/2008-December/000074.html
e nel blog di Tim: http://blogs.sun.com/timf/en_IE/entry/6777694_need_ability_to_control

Continua lo sviluppo di OpenSolaris ed ovviamente prosegue l’integrazione delle sue funzionalità più spinte con le varie componenti del sistema operativo. E’ stata resa disponibile una feature che permette di integrare gli snapshot di ZFS con nautilus il “filemanager” di GNOME. In questo modo potrete andare a ritroso nel tempo e recuperare molto agevolmente le vecchie copie dei file più importarti che avrete provveduto a rovinare e/o perdere!!!
Una volta aggiornato OpenSolaris alla release snv_100 basterà installare due pacchetti ed effettuare alcune “correzioni”, per primo installiamo i pacchetti necessari:

pfexec pkg install SUNWzfs-auto-snapshot
pfexec pkg install SUNWgnome-time-slider

il primo installa una serie di servizi sviluppati da Tim Foster che effettuano una serie di snapshot in automatico ogni 15 minuti, ogni ora, ogni giorno, ogni settimana ed ogni mese (ovviamente potrete personalizzare la frequenza e la quantità di snap da conservare, maggiori info le trovate nel README di zfs-auto-snap), mentre il secondo pacchetto installa l’utility di configurazione del time-slider consentendovi di scegliere quali filesystem zfs includere nei salvataggi (di default tutti ovviamente).
Come accennato, installare questi pacchetti non basta, in quanto a causa di un baco nel pacchetto di zfs-auto-snapshot l’utente che si occupa di effettuare gli snap non ha abbastanza privilegi; poco male, sistemiamo noi il tutto; per prima cosa togliamo il lock all’account zfssnap (come utente root):

# passwd -N zfssnap

e aggiungiamo i privilegi di amministrazione ZFS (tutto su una riga):

# echo "zfssnap::::type=role;auths=solaris.smf.manage.zfs-auto-snapshot;profiles=ZFS File System Management" >> /etc/user_attr

Ora non rimane altro da fare che attivare la nostra “macchina del tempo” per filesystem con System/Administration/Time Slider Setup:

Impostazioni della Time-Slider

ora potrete scegliere quali filesystem “proteggere” e lo spazio che intendete lasciare libero sul disco fisso; per default al raggiungimento dell’80% dello spazio occupato verranno cancellati gli snapshot più vecchi. Ecco cosa ho scelto di salvare sulla mia macchina:

Qui si possono scegliere quali filesystem salvare

Dopo qualche minuto potrete controllare se il servizio sta facendo il proprio lavoro con:

$ zfs list -t snapshot | grep auto-snap

ora, se aprite nautilus avrete la possibilità di “viaggiare nel tempo” (chiccando sull’icona “Restore”) e recuperare i vecchi file semplicemente muovendo la slide avanti ed indietro; ecco la mia home ad esempio:

ecco come si presenta la mia home "ora"

ed ecco evidenziato un file che avevo cancellato qualche minuto prima:

...e questa era la mia home qualche istante prima!

facile vero? Potete trovare ulteriori immagini e spiegazioni dettagliate nel blog di Erwan Chénedé.

Continuano gli aggiornamenti di OpenSolaris in previsione del rilascio della prossima versione stabile 2008.11, infatti questo fine settimana il repository dei pacchetti è stato aggiornato alla snv_98. Con questa nuova release è stato inclusa anche la versione 13 di ZFS, infatti, dopo aver aggiornato alla nuova release è possibile aggiornare i metadati del proprio pool con:

# zpool upgrade -a

questa opzione è immediata ed indolore (tuttavia consiglio sempre di fare il backup di tutti i vostri dati PRIMA di eseguire qualsiasi aggiornamento, SEMPRE!!!) tuttavia occorrerà anche aggiornare il booloader per fargli “comprendere” il nuovo formato, altrimenti vi troverete ad affrontare un bel problema al prossimo reboot!
Prima di riavviare la macchina occorrerà digitare i seguenti comandi:

# touch /etc/system
# bootadm update-archive
# /boot/solaris/bin/update_grub

se invece vi siete fatti prendere dalla fretta e vi trovate con GRUB che mostra il suo bel prompt nero basterà fare il boot con un liveCD aggiornato (altrimenti non riuscirà a leggere il nuovo formato di ZFS) scaricabile da genunix.org ed agire così:

# mkdir /tmp/rpool
# zpool import -f -R /tmp/rpool rpool
# mount -F zfs rpool/opensolaris-X /mnt
# touch /mnt/etc/system
# bootadm update-archive -R /mnt
# /mnt/boot/solaris/bin/update_grub# umount /mnt
# zpool export rpool

ricordatevi di sostituire opensolaris-X con il nome del vostro boot-environment appena aggiornato; dopo il reboot tutto tornerà a funzionare perfettamente!
Se volete approfondire trovate maggiori informazioni qui.

Leggendo la man page di zpool e zfs vi sarete certamente accorti che esiste la possibilità di “aggiornare” la struttura usata dal filesystem a versioni più recenti (ma non è possibile tornare indietro). Recentemente è stata rilasciata la release 12, ma se come me intendete aggiornare il pool di boot fate attenzione!
Infatti dopo questo upgrade è necessario reinstallare GRUB, altrimenti al prossimo riavvio non andrete oltre il prompt del bootloader!
I passi da seguire per un aggiornamento “pulito” sono:

# zpool upgrade -a

e verranno aggiornati tutti i pool, oppure se volete aggiornarne solo uno sostituite al posto di -a il nome del pool; a questo punto aggiornate GRUB:

# installgrub /boot/grub/stage1 /boot/grub/stage1/dev/rdsk/c5t0d0s0

ovviamente nel vostro caso sostituirete c5t0d0s0 con il device del vostro disco.
Se invece siete stati impazienti o incauti e già vi trovate con il boot di OpenSolaris andato basterà inserire nel lettore un CD live con le ultime release (scaricabile da www.genunix.org) e lanciare l’ultimo comando dalla console.

Ispitato dal post di sickness riguardo la possibilità di capire quali file sono cambiati rispetto ad uno specifico snapshot mi sono “divertito” a realizzare questo semplice script che non fa altro che ispezionare tramite il comando diff un filesystem ZFS e un suo snapshot specifico. In fondo lo script effettua dei semplici controlli e migliora l’aspetto dell’output per renderlo “leggermente” più leggibile, magari in future versioni integrerò anche altre features. L’unico vincolo richiesto è che il filesystem ZFS che si intende “ispezionare” sia attualmente montato.

Le operazioni svolte sono semplici:

1. viene impostata su “visible” la proprietà “snapdir”
2. viene eseguito il diff tra il mountpoint del filesystem e lo snapshot
3. viene ripristinala la proprietà “snapdir” al suo valore originale

La chiave del funzionamento dello script è essenzialmente il fatto che è possibile “montare” gli snapshot di un filesystem impostando la proprietà con:

# zfs set snapdir=visible

a questo punto potremmo accedere (in modalità read-only) a tutti i file del filesystem così come apparivano al momento della creazione dello snapshot. Per accedervi possiamo operare in questo modo:

$ cd .zfs/snapdir//file_interessato

facile vero?

Per usare invece il mio script e controllare quali file sono cambiati, cancellati oppure aggiunti basta il comando:

$ pfexec ./snapdiff rpool/export/home/luca snap-2008-08-15

e vedremo quali file sono cambiati nella mia home dal giorno 15 agosto.