Btrfs è un filesystem introdotto nel kernel Linux a partire dalla versione 2.6.29-rc1, progettato per competere con il robusto ZFS di Sun Microsystems. Btrfs possiede molte caratteristiche avanzate come compressione trasparente, snapshots, deframmentazione online, bilanciamento dei blocchi per ripartire il carico e copy-on-write.
Phoronix ha effettuato diversi test sulle prestazioni di Btrfs che sottolineano una tendenziale superiorità in termini di prestazioni rispetto ad EXT4. Già da questo test, effettuato con un SSD, i risultati variavano in maniera molto consistente a seconda delle configurazioni adottate: lzo, zlib, ssd, space_cache e nobarrier.
Prendendo un normale hard disk a 5400rpm le prestazioni subiscono un brusco calo in configurazioni normali, i risultati nel caso peggiore sono fino a 6 volte peggiori rispetto ad EXT4. Il giovane Btrfs riesce a competere solo se utilizzato con l’opzione -nobarrier riducendone così l’affidabilità. Personalmente credo che Btrfs abbia un potenziale enorme ma l’elevata differenza di prestazioni tra le diverse configurazioni rischia di essere penalizzante. Stando ai test quindi, usare Btrfs se si possiende un SSD è una scelta ottima, per gli altri EXT4 rimane un’opzione di tutto rispetto. Nel frattempo Phoronix sta già preparando un approfondimento sui consumi di memoria e processore, attendiamo.
Via | Phoronix
Kim Allamandola
03 ott 2011 - 18:04 - #1Uso in produzione sia per desktop che per server il btrfs da quando son dovuto
tornare a GNU/Linux con la morte della SUN, per gli ssd uso:
discard, compress, ssd
passati all’install dal CD alternate di Ubuntu, space_cache per ora non lo ho
ancora provato seriamente… Sinora non ho avuto particolari problemi salvo
dover rifare i volumi coll’aggiornamento del formato on-disk mi sembra del
2.6.31 (copiare i dati col vecchio kernel su altri volumi, rifare il fs col
nuovo kernel e ributtare i dati dov’erano prima) ed un curioso baco, capitato
ad un amico che ha portato alla saturazione dello spazio disco riempito dai
metadati (risolto montando a mano con danger_del_log_tree, opzione aggiunta da
una patch che girava sulla LKML all’epoca).
Su dischi a piattelli per ora il vecchio reiser3 viaggia come una scheggia sia
su sata desktop che ultra-320 che sas vari… L’ext4 *non mi piace* come non mi
son mai piaciute le versioni precedenti!
Ad ogni modo confrontare lo zfs col btrfs è assurdo: lo zfs è una data storage
system, il btrfs un filesystem. lvm+btrfs possono essere paragonati allo zfs
ma fanno una figura barbina…
Giacomo Picchiarelli
03 ott 2011 - 18:12 - #2@Kim Allamandola
Ero un fan di ReiserFS.
Me lo consiglieresti in caso di file multimediali? Film musica in grandi quantità? Con dischi normali intendo. Non lo uso da anni.
barra
03 ott 2011 - 20:39 - #3@Kim: sono il solo che ha avuto casini a non finire con RaiserFS? Le prestazioni erano mostruose ma mi è sempre sembrato “delicato”…..
Black_Codec
03 ott 2011 - 21:09 - #4ReiserFS l’ho usato tempo fa sul mio pc di casa e devo dire che per file multimediali quali video e musica è ottimo. Scarse prestazioni con piccoli file e con le dette “vie di mezzo” però…
Btrfs lo installerei solo per la funzionalità di snapshot, vi è mai capitato di maledire il giorno in cui avete compilato quella cosa magari anche forzando qua e la per rendervi conto che non ne valeva la pena? Ecco ripristinare lo stato iniziale con btrfs è possibile in 2 passi senza diventar scemo a ripulire qua e la… D’altro canto le prestazioni su dischi sata sono penose specie se paragonate a ext4 o ReiserFS.
In conclusione ritengo btrfs il file system del futuro o comunque quello che potrebbe dare l’impronta migliore, certo se lo ottimizzassero per i comuni mortali probabilmente prenderebbe piede in più distro, attualmente se non erro solo fedora mediante plugin supporta la creazione in maniera automatica di uno snapshot ad ogni pacchetto installato tramite package manager.
Kim Allamandola
03 ott 2011 - 22:07 - #5@Giacomo Picchiarelli #2
Ti consiglio tranquillamente il reiser3, il 4 non l’ho mai seriamente provato
ma col tre ho varie macchine in produzione, per lo più desktop e qualche web,
mail server senza aver mai avuto seri problemi.
Ai tempi in cui ero su GNU/Linux, prima del “ritorno”, quando Gentoo usava
ancora la numerazione 1.x anziché gli anni, usavo l’XFS, non va male ma è
enormemente più lento del reiser e per quanto abbia comodi tools xfs_* non
c’è storia per un uso desktop!
@barra #3
casini non né ho mai avuti, se non causati da problemi hw, ad ogni modo non
ho mai considerato la presenza e la funzionalità di tools di recovery come
di mio interesse: se qualcosa va storto c’è il backup, altro non ha senso
se non per analisi post-mortem…
@Black_Codec #4
Il reiser è veloce *sopratutto* coi file piccoli…………
Per quanto riguarda gli snapshot: li hai mai usati? No perché lo zfs ha un
comodo servizio dell’smf auto-snapshot e gli snapshot stessi non sono
visibili nel normale fs se non in .zfs/ nella root del volume. Il btrfs
gli snapshot li ha fatti a mano, visibili e nella root del volume e non
c’è una funzione di rollback come lo zfs: se vuoi fare un restore devi
buttare via il vecchio volume e tornare al nuovo, a mano.
Non per polemica ma da come scrivi sembra tu non abbia mai usato né il
reiser né il btrfs, se mi sbaglio hai le mie più sentite scuse, unite
alla preghiera di rileggere quello che scrivi…
Black_Codec
04 ott 2011 - 04:55 - #6@Kim:
Bo io col ReiserFS ho notato come ho detto lentezza con piccoli file e con le vie di mezzo, cioè file da 5/8 mega. Poi sarà un caso, comunque lo usavo sul box multimediale e andava da dio specie con gli mkv che pesano assai.
Per quanto riguarda zfs non l’ho mai provato ne ho mai asserito di averlo fatto, btrfs l’ho provato su una arch e in virtuale su fedora col plugin che dicevo prima, puoi farlo a mano lo snapshot e per carità io parlavo di automatismi come ad esempio fa windows, creare un punto di ripristino ad ogni installazione poi se vogliamo scendere nel filosofico non so.
De facto io btrfs l’ho provato sul netbook e tra btrfs e ext4 (ReiserFS sul netbook non m’ha fatto entusiasmare) preferisco ext4 tutto qua.
ice
04 ott 2011 - 09:27 - #7Spero che hardware come il MicroServer di HP stimolino la nasciata di distro Linux x NAS/SAN che usino questi nuovi fs e comincino a diffonderli (OpenFiler ha una release del 2009 e poi una di aprile 2011 e ancora non supporta btrfs)
facendoli cosi uscire da questa fase di beta
A suo tempo avevo provato NexentaStor ma era un po troppo instabile per i miei gusti
Forse colpa dell’hardware un po troppo pc per il targhet cui la distro si rivolge
Qualcuno ha esperienze stabili e soddisfacenti con Nexenta o altre derivate IllumOS?
Martin45
04 ott 2011 - 10:02 - #8@Barra: non sei il solo, pure io passavo le notti con reiserfsck… :(
Caso vuole che i primi problemi con questo FS sono capitati quando il Sig. Reiser è stato accusato di uxoricidio.. :P
Kim Allamandola
04 ott 2011 - 10:43 - #9@ice #7
Ho *ottime* esperienze con OSOL e con FreeBSD+zfs fatto in casa, con Nexenta
non ho significative esperienze, c’ho giocato, fa il suo lavoro ma non ho che
due macchine domestiche di prova…
Sul discorso stabilità tieni presente che lo zfs non gradisce CPU a 32bit e ha
bisogno di ram, arc, la cache zfs vuole quanta più ram possibile. Diciamo che
se hai meno di 2Gb di ram lo zfs non fa per te :-) se hai da 2 in su non c’è
nulla di meglio sulla piazza!
@Black_Codec #6
Non so come hai fatto a notare lentezze per piccoli file nel reiser… Come le
hai notate? Cioè non è che sono lentezze di una qualche applicazione che sopra
il fs gira ed ha algoritmi di traversing discutibili? Lo zfs l’ho tirato in
ballo io per la questione degli snapshot ad ogni install/update: con lo zfs
puoi clonare un be, ovvero fare un clone bootabile con tanto di voce in grub
che occupa solo i bit di differenza rispetto al be d’origine+128Kb in un
istante (beadm create nomeCheTiPare). Non puoi altrettanto farlo col btrfs, non
in maniera usabile cmq, non per poter bootare o restore-are facilmente una
root. Quello di cui parli di Fedora non è uno snapshot è usare gli snapshot con
un alquanto poco efficiente sistema di bindiff tra il volume originale e il
nuovo, una specie di freebsd-update molto rozzo di cui il btrfs è solo una
componente minimale.
Per quanto riguarda le performance del btrfs sui dischi a piattelli non mi
stupisce, va lento quanto l’XFS od il JFS, sono fs pensati per dischi SCSI
o SAS più che per SATA casalinghi magari da 2.5″… Ad ogni modo il reiser3
va molto meglio dell’ext4 almeno come performance (non ho volumi in uso ext4,
ho solo fatto prove quindi non so che problemi eventualmente dia nel tempo)…
Sul discorso NAS GNU/Linux non mi interessa, li IllumOS/OI/Nexenta sono più
che ferrati ed usabili, GNU/Linux ha in più rispetto a FreeBSD iSCSI e poco
altro, che peraltro IllumOS ha assai più completi e supportati… Può al più
interessare per i nas domestici, come Netgear fa da anni, per poter avere ben
poca ram in uso (anche MilaX/DSS ciuccia molta più ram di GNU/Linux) ma non
certo per altre caratteristiche…
@Martin45 #8
Scusa ma quante volte t’è capitato e perché? Nel senso se il tuo hd ciocca non
c’è fs che tenga, se per una volta, caso più unico che raro, l’fs da solo si
mette a cioccare, bé pigli un backup e spiani. I vari *fsck han senso IMO solo
per controllare che tutto sia a posto non per altro!
ice
05 ott 2011 - 08:19 - #10@ #9
con la versione usata di nexenta io ho avuto seri porblemi di networking
forse le nic della realteak non erano ben supportate in quella release
ma ripeto l’ho usato su hardware pc e non su hardware server
Chiaramente il kernel Solaris ha una matrice di compatibilità e supporto hardware molto piu ristretta di quella di un kernel linux
per questo preverirei la diffusione di distro Linux
un po come avvenuto per i netbook
Poi con distro linux (non super specilaizzate tipo Openfiler) è possible aggiungere facilemtne Xen e cosi hai un nas che ti gestisce interfaccia web di management + VMs+ storage
Considerato che non lo farei girare su un server con hardware didicato allo storage e magari doppia controller e doppio backplane……preferisco stare sul semplice e tenero lo storage a livello di bare-metal e che implementi un fs per il quel siano disponibili tanti tool di recovery
Altrimenti ti perdi parte dei vantaggi di un raid software
metti che ti ciocca l’hardware e un altro pc che hai a disposizione non fa girare correttamente un kernel solaris nato e pensato per server e/o workstation sun (ai tempi, adesso non credo le facciano piu)
Kim Allamandola
06 ott 2011 - 11:34 - #11@ice #10
Hum… Il supporto hw di OpenSolaris è anni luce avanti rispetto al vecchio
Solaris 10, spesso è superiore a GNU/Linux… Più che altro, ipotizzo non
conoscendoti, penso che i tuoi problemi siano dovuti al fatto che tentavi di
usare/configurare la rete come con GNU/Linux.
Su Osol un’interfaccia di rete per essere visibile deve essere plumb-ata
ifconfig $nomeNic plumb
e $nomeNic non è eth[[0-9]+ ma il nome_del_driver[0-9]+ e alle volte c’è
più di un driver per alcune nic (vedi ad es. http://is.gd/w4t9yf) in più
ci sono due diversi modi di configurare la rete, uno classico ed uno nuovo,
quello nuovo, che non supporta ancora lo spanning tree ecc è nwam e si
configura in /etc/nwam/llp (llp == link layer profile) mentre nel metodo
classico, incompatibile, avevi un po’ di file sparsi. Anche route è diverso:
route add default gw $ip non può funzionare; se aggiungi una default route
è ovvio che l’argomento successivo sarà il gateway, il risultato è che route
tenta di risolvere gw… Qui si da semplicemente route add default $gw_ip
ecc. Nexenta usa l’userspace GNU, Ubuntu per la precisione, ma chiaramente
tale userspace deve confrontarsi col sistema su cui gira, i comandi sono
gli stessi come nome (quasi) ma non come argomenti.
Per il discorso RAID mi sa che non conosci abbastanza lo zfs :-) se hai una
macchina in mirror (2 HD) e uno dei due moure l’unica cosa da fare è prendere
il disco morto, sostituirlo e dare zpool attach fine. Non hai
problemi a bootare l’os in un pool degradato se non puoi hot-swappare i dischi.
All’attach lo scrub è automatico e si può “rallentare” in base alle necessità
di carico del sistema e cmq non rende la macchina “inusabile”.
Sul discorso recovery infine io non considero *mai* il recovery: se qualcosa
va storto c’è il backup, altrimenti sei fottuto. Il recovery lo tengo in
considerazioni solo per questioni forensi o di sicurezza (perdita dati
sensibili se non cifrati ecc).
Osol ti gira su qualunque macchina, sui miei laptop c’è dalla prima SXDE, prima
che diventasse CE e poi Indiana… Mai un problema hw e spesso performance
superiori a GNU/Linux. Osol *non è fermo* è “morto” ma la community è sempre
attiva, IllumOS continua a essere sviluppato, idem Nexenta, idem lo stesso
Solaris Express ora Oracle che su Osol si basa, OpenSolaris non è *mai* stato
pensato solo per le Workstation SUN!