Per una distribuzione che procrastina Btrfs c’è un’azienda che si appresta a distribuire ZFS per Linux. L’avevamo anticipato all’inizio dell’estate: Brian Behlendorf di LLNL sta lavorando su ZFS per aggirare quei limiti della licenza CDDL di Sun Microsystems che finora hanno impedito il porting del filesystem. Non ci è voluto molto perché arrivasse a un risultato concreto. Il modulo andrà compilato a sé.
Sussistono, infatti, due problemi alla definitiva integrazione: come sottolineato in occasione dell’annuncio di giugno, a causa delle incompatibilità di licenza il modulo di LLNL non potrà essere implementato direttamente nel kernel. Un altro aspetto (che ZFS condivide con Btrfs) riguarda la creazione di applicazioni compatibili. Senza un programma come Time Slider il filesystem ha poco senso.
C’è poi un terzo problema che non si può sottovalutare. Sia Btrfs, sia ZFS sono attualmente nelle mani di Oracle. Ciò riguarda un elevato numero di progetti open source, ma nella circostanza diventa un aspetto primario. Escludendo LVM2 (con caratteristiche totalmente differenti) i progetti più interessanti per gli snapshot dei dischi sono entrambi nelle mani di una sola azienda. Finché li vorrà mantenere.
Via | Phoronix
Seguici
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
(2 Voti | Media: 4 su 5)
ekerazha
28 ago 2010 - 12:39 - #1“Senza un programma come Time Slider il filesystem ha poco senso.”
Come se gli snapshot fossero l’unica caratteristica interessante di ZFS, mah…
Jak696
28 ago 2010 - 15:18 - #2Beh, almeno per un utilizzo desktop è una delle uniche che lo può far preferire a ext4.
chiaramente in ambieto server è tutta un’altra storia.
lucapas
28 ago 2010 - 15:45 - #3Ok, sono ignorante, ma non sono ancora riuscito a capire cos’hanno in più Btrfs e ZFS rispetto a Ext4. Mi pare anzi, dai test di phoronix, che ZFS fosse piuttosto indietro in quanto a performance, mentre Ext4 e Btrfs se la battevano ad armi pari!
Kim Allamandola
28 ago 2010 - 18:56 - #4@#3 l’ext4 come l’xfs, il raiserfs, lo jfs ecc sono filesystem tradizionali; né
hai uno per partizione o volume lvm, ridimensionarli è difficile, non puoi
snapshottarli (gli snapshot lvm sono inusabili, xfs è snapshottabile solo a
volume offline ecc) non puoi replicare facilmente i dati altrove: puoi via
dd salvare un’immagine, ma non è una copia incrementale, puoi usare
rsync ma è molto più lento di una copia a livello di blocchi e se anche
sposti solo un file da una dir ad un’altra ti reinvia l’intero file…
lo zfs include un gestore di volumi che al di la di essere n volte più semplice
e flessibile di mdadm+lvm+fs permette di creare quanti volumi (iow
“partizioni”) che occupano all’inizio 128K e crescono via via che vi salvi
dati usando lo spazio libero dello zpool. In altri termini le “partizioni”
diventano facili da gestire quasi quanto le directory.
Non finisce qui; es: hai un portatile con un solo disco e lo vuoi backuppare
come fai con le soluzioni GNU/Linux attuali? La più comoda è replicare
su un disco usb le partizioni del disco del laptop, via snapshot btrfs con
rsync sincronizzare tutto (senza gli snapshot non puoi salvare la root ma
solo la /home quindi un ripristino dell’OS senza reinstallare non è possibile)
step:
crea le partizioni sul disco usb e montale
crea uno snapshot
rsync -a –delete …. (op. incrementale ma leeenta)
rimuovi lo snapshot
smonta le partizioni
con lo zfs:
zpool create bkup /dev/disco_usb
zfs snapshot -r rpool@nome_che_ti_pare
zfs send -Dr rpool@nome_che_ti_pare | zfs recv bkup
zpool export bkup
non devi far nullaltro, niente fstab, niente mount a mano ecc
ancora hai quote, copie multiple dei blocchi di un volume, checksum dei
singoli blocchi, compressione, deduplicazione… Tutto con
zfs set proprietà=valore pool/vol
sul mio laptop con opensolaris con la compressione sono passato da
circa 10Gb si OS a 4.8Gb, e il sistema è più veloce (l’IO su un laptop
richiede più tempo della (de)compressione real-time) con la dedup
sono sceso nella /home da 280Gb a 200Gb… Ho diviso la /home in
vari volumi (musica, video, progetti, …) che hanno policy di backup
e replica differenti… Puoi anche fare 1000 cose in più incluso avere
un volume condiviso via nfs o samba o iscsi con un solo comando
zfs sharenfs=on pool/vol
ecc.
sono già stato sin troppo prolisso ma spero di aver reso l’idea. Allo zfs
manca ancora una cifratura tipo luks (ma col port GNU/Linux nulla
vieta di fare un pool dentro un vol luks) e una replica dei dati tipo
lustre/hertbeat. Per il resto non ha eguali; soluzioni tipo veritas, tivoli
ecc sono mostri assurdi ed inusabili se paragonati allo zfs.
lucapas
28 ago 2010 - 21:28 - #5Ah, cavolo! Beh, io lo avevo detto che sono ignorante in materia! :D
Ho capito neanche la metà di quello che hai scritto. :lol:
Però ti ringrazio per le spiegazioni.
sherpya
28 ago 2010 - 21:39 - #6@4
con rsync fai anche la root in esecuzione e funziona :D (non e’ come lo snap pero’ va bene uguale) ;D
a parte questo la prima volta che mi sono trovato a dover fare volumi su zfs ho detto
‘ora come divido, quanto do a questo volume…’
mi sono accorto che non c’e’ questo problema, i volumi hanno lo spazio condiviso e lo prendono via via che si usa, non devi stare a pensare quanto grosso lo vuoi fare e poi fare il resize, questo concetto non applica
insomma
28 ago 2010 - 22:59 - #7@Kim Allamandola:
ma quanto di tutto ciò è possibile (o è in roadmap) anche con Btrfs?
flask
29 ago 2010 - 10:40 - #8Chi ha tempo e voglia di spiegarmi brevemente quali sono le restrizioni della licenza ZFS che non permettono una facile implementazione in altri OS e che, mi sembra di aver capito, costringa a creare interfacce e strati software supplementari per poterla utilizzare senza il rischio di violazione di clausole, ad esempio sui sistemi GNU/Linux ? La particolare licenza ZFS è la causa per cui anche Apple ha deciso si abbandonare la sua implementazione in Mac OS X ?
Kim Allamandola
29 ago 2010 - 12:13 - #9@7 non so darti una roadmap di lungo periodo per il btrfs; non né
ho mai trovate online… Al momento il btrfs supporta: gli snapshot
che sono più che altro dei cloni zfs, sono usabili anche se non
comodi come lo zfs; la compressione solo come opz di mount ma
più intelligente dello zfs, non comprime tutto ma solo quei blocchi
la cui compressione fa risparmiare realmente spazio (prova a
comprimere un mp4 e un file di testo poi guarda i risultati) per il
resto il btrfs è come il reiserfs con la possibilità di crescere e
dimagrire ma senza gestione di volumi e con la necessità di
deframmentare il tree.
@lucapas provo un piccolo summary:
* compressione sui tuoi HD hai mooolti file; prova a comprimerne
qualcuno (bzip, rar, zip ecc) e guarda quanto spazio in meno occupi;
con lo zfs ed il btrfs lo fai ad un livello più basso dei file e delle dir,
al livello dei blocchi dati, degli 0 ed 1 sul tuo disco in automatico
senza che tu debba decomprimere ogni volta (prova a dare dal
terminale “find /usr/share/docs -iname ‘readme*.gz’” poi apri con
vim un file a caso se vim è decentemente compilato ti decomprime
il file in automatico il file e a te sembra di lavorare con un file di
testo semplice e risparmi un po’ di spazio disco!). Oggi le CPU sono
“potenti” mentre gli HD specie sui portatili sono “lenti” pertanto
avere file più piccoli e (de)comprimerli usando più CPU è quasi
sempre vantaggioso.
* dedup(licazione) immagina di avere molte foto e documenti:
quanti pixel dello stesso colore e/o lettere dello stesso font ci
saranno? Con la dedup salvi un pixel per colore od un carattere
e ti ricordi in quanti file compare; non è esattamente così ma
rende l’idea: per ogni blocco dati di una certa dimensione fai un
hash (es md5) e se trovi che esiste già anziché salvare l’intero
blocco lo linki solo al blocco uguale. Ad esempio se hai 10 copie
dello stesso file ovunque sul disco occupi un solo file e linki gli
altri a questo; se dividi un video in clip o lo monti da delle clip
salvi solo i singoli fotogrammi senza occupare spazio in più ecc…
anche qui per le CPU/HD odierni è quasi sempre vantaggioso
deduplicare.
* send/recv sei hai 250Gb da salvare e non fai un backup
incrementale (es via dd) ad ogni backup devi copiare 250Gb… Se
fai un backup logico incrementale (es via rsync) ovvero passi solo
quei file che sono cambiati dal backup precedente devi ogni volta
guardare *tutti* i file/dir cosa che richiede tempo (IO e CPU) ed
inoltre se un file di 5Gb cambia di 1Mb devi comunque spedire
5Gb cosiccome se sposti un file da una dir ad un’altra (es un film)
devi reinviare il file nella nuova posizione in ultimo (@4) rsync se
rsync-i la / in uso non uno snapshot e/o un volume smontato hai
il backup di /dev, /dev/pts ecc con user/group solo numerici cosa
che ti rende inusabile l’OS al restore (per lo meno devi sistemare
i permessi) con l’invio a blocchi invii *solo* i bit che sono cambiati
ed essendo un livello sotto i file/dir non hai problemi di permessi
o simili: sposti solo bit.
@8 sarò maligno ma cose come i driver nvidia non sono GPL, non
sono neppure Open! Eppure quasi tutte le distro li hanno installabili
in automatico… Credo piuttosto che il problema sia dover riscrivere
3/4 del vfs linux per lo zfs… Linux è un kernel con molti sviluppatori
ma come Linus stesso ha detto è oggi una montagna di codice non
proprio ben pensata; Opensolaris (genunix) è anni luce avanti e sono
avanti anche molti aspetti dei kernel di {Free,Open}BSD pensa solo
che su osol puoi sostituire CPU e banchi ram a sistema live, pensa a
quanti thread può gestire opensolaris, pensa allo stack ip di OpenBSD
Linux ha molte cose ed è molto diffuso però non è diverso da
mostri come X e simili. Non a caso Canonical da tempo rimugina di
cambiare kernel (e nel caso di X si parla da anni di avere un’altro X
anche se in questo caso non ci sono proprio alternative open…)
Mi scuso per il lungo commento
flask
29 ago 2010 - 14:13 - #10scusarti ??? :) @Kim, quello che dici è estremamente interessante ed utile… oltre che essere molto chiaro
Gianluca Sforna
29 ago 2010 - 23:57 - #11Non so nulla di ZFS, ma so per certo che btrfs non è “nelle mani di una sola azienda. Finché lo vorrà mantenere.” intanto perchè il codice è già GPL e incluso nel kernel, quindi nessuno ce lo può togliere e poi perchè la Red Hat impega sviluppatori a tempo pieno sul progetto (basta dare una occchiata ai commit per vederlo)
lucapas
30 ago 2010 - 10:54 - #12Wow! Altro che scusarsi, grazie davvero Kim, stavolta sei stato molto chiaro e ho capito bene tutti i vantaggi che ci sono nell’applicazione di un simil FS. Molto interessante soprattutto la dedup(licazione)!
Stavolta una birra te la sei proprio guadagnata! ;-D :beer:
Alberto Villa
01 set 2010 - 10:30 - #13“Senza un programma come Time Slider il filesystem ha poco senso.”
come se non si potessero creare snapshot a mano…