
Zfs è considerato da molti il filesystem più avanzato e lo vorrebbero anche su Linux. La sua licenza, CDDL, purtroppo ne impedisce il porting per l’incompatibilità con la GPL.
Phoronix ha condotto una serie di benchmark che hanno messo a confronto il gioiello di casa Sun con il suo omologo nato in ambiente Linux: Btrfs. Dai risultati si evince che nella maggior parte dei casi Ext4 e Btrfs sono più veloci di Zfs e che quest’ultimo è sicuramente la scelta migliore su FreeBSD.
Una buona notizia per tutti quegli utenti che aspettavano Zfs per linux o che lo usano attraverso il layer Fuse. Potrebbero provare Btrfs con molte soddisfazioni.
Via | Phoronix
Cesoia
28 lug 2010 - 14:40 - #1Diciamo che e’ la GPL ad esser incompatibile non solo con CDDL ma praticamente con tutto.
Kim Allamandola
28 lug 2010 - 14:51 - #2@Cesoia
Oggi la GPL _mi_piace_ nel senso che essendo alla fine del mondo
copyright-based (modello che andava per l’industria meccanica dei
primi del ‘900 ma *non* va per l’informatica) è bene aver una
protezione forte. Ci sono tonnellate di codice *BSD in progetti
commerciali che nulla danno alla community; con la GPL puoi
portarli in tribunale (e si è già fatto molte volte) con la BSD no.
credo che la storia CDDL-GPL sia fumo; i driver nvidia non sono GPL
e non sono manco opensource, eppure i moduli ci sono da anni e la
maggior parte delle distro li pacchettizza, a parte ma li da.
#ifndef flame
Il fatto è che per portare lo zfs su Linux bisogna riscrivere tutto
il vfs, cosa tecnicamente difficile; e sopratutto bisogna ammettere
che Linux è anni luce indietro e assai peggio progettato di genunix
(il kernel di Solaris/Opensolaris). Oggi Linux ed X sono i prodotti
*nix _peggiori_ sulla piazza e purtroppo, come curiosamente capita
sempre con i prodotti di minor valore si diffondono prima e a
scapito di altri (Microsoft è spazzatura ed è la più diffusa, Apple
è solo un po’ meno spazzatura di Microsoft per il fatto che osx ha
una base unix, GNU/Linux è un blob di codice ma è più diffuso dei
*BSD ecc.)
#endif // flame
Spero che Canonical visto debian/kfreebsd si decida a passare nel
medio periodo sul kernel di freebsd o magari anche tentare di
assumere i developer ex-Sun di genunix che da Oracle stanno scappando
riprendendo un nuovo ubuntu-opensolaris (come fa limitatamente
nexenta)
ice
28 lug 2010 - 15:53 - #3io faccio notare una cosa che la dice tutta di come le grandi aziende dell’IT, Oracle in primis considerino l’opensource
UNA VACCA DA MUNGERE
btrfs è un porgetto nato in seno a Oracle quando questa non aveva ancora aquisito Sun ed aveva bisogno delle caratteristiche avanzate di quel fs per il suo Oracle-Linux
.
Con un incipit come questo ci si sarebbe potuti aspettare che acquisita Sun, Oracle si muovesse per cambiare la licenza di zfs e integrarla in linux
e invece……..stanno lentamente soffocando OpenSOlaris
e sono sempre piu i developer che abbandonano tanti dei progetti Open patrocinati da mamma Sun
Soulsuke
28 lug 2010 - 17:04 - #4Solo 3 rapide osservazioni:
1. ZFS su FreeBSD è allo stato _sperimentale_, non è portato completamente e richiede del tuning. È comunque alquanto inutile fare dei benchmark ora, visto che con FreeBSD 9 (che teoricamente dovrebbe uscire questo autunno) il supporto sarà migliorato e portato all’ultima versione. Mi sarebbe piaciuto vedere un paragone tra lo ZFS su OpenSolaris alla 134 e ext4/btrfs su Ubuntu, giusto per rendere i risultati più significativi, in quanto al momento mostrano un rapporto tra un fs allo stato _sperimentale_ contro due fs pronti per l’impiego in produzione.
2. Riguardo all’affermazione “Potrebbero provare Btrfs con molte soddisfazioni” mi permetto di dissentire: ho provato il btrfs con Ubuntu (nightly), e non è minimamente vicino allo ZFS in quanto a feature: in primis va creato un volume LVM in cui creare le partizioni btrfs, ma se si creano più partizioni dentro un volume, è impossibile cancellarne una senza distruggere contemporaneamente anche le altre. È quindi necessario creare una serie di volumi LVM, ognuno con dentro una sola partizione btrfs. Ok, tutto ciò permette di ridimensionare le partizioni a caldo tramite i relativi comandi (lvm+btrfs), ma è comunque molto macchinoso. Inoltre, il btrfs non fa un resizing automatico delle partizioni. Non parliamo di dedup e send incrementali, ovviamente. Parliamo invece della frammentazione del fs: ogni file _più_piccolo_di_4_MiB_ riserverà un intero settore di 4MiB sul disco (per completezza, sullo ZFS accade una cosa simile, ma a blocchi di 128KiB), ed è quindi necessario deframmentare il disco ogni tanto (sempre col comando btrfs). Certo, il btrfs è un passo avanti rispetto ai vecchi fs basati su partizioni, ma è comunque inferiore di _molto_ allo ZFS. HAMMER sarebbe un’alternativa molto più valida, ma purtroppo è solo per DragonflyBSD.
3. Va fatto presente che il conflitto GPL/CDDL non è l’unico inconveniente ad un porting su Linux dello ZFS: per poterlo implementare in modo performante, bisognerebbe riscrivere una parte del kernel Linux (leggete i board, please).
Cesoia
29 lug 2010 - 11:22 - #5@tutti
I brevetti sono una cosa,la GPL un’altra.Nessuno applaude al sistema attuale dei brevetti ma non per questo la GPL ne e’ giustificata.
Non esiste un _solo_ tipo di software quindi e’ completamente fuori luogo l’uso scriteriato della GPL principalmente per fini ideologici.
Se la GPL e la sua viralita’ hanno un senso per evitare l’estensione proprietaria di standard aperti, non ha alcun senso applicarla all’applicativo che _usa_ tali standard.
Il sorgente non e’ un diritto del consumatore e non e’ un dovere dello sviluppatore.Quindi le licenze che obbligano a dover fornire il proprio lavoro secondo scelte altrui sono _privazione_ di liberta’.
Io rispetto le tue idee,tu rispetti le mie.Cosi’ funziona il file_based come CDDL o MPL.Se fai caso non cito mai la BSD perche’ troppo blanda ed in un mondo come quello di oggi ha veramente poco senso.
Per quanto riguarda i driver nvdia esiste un wrapper di compatibilita’ che li slega totalmente dal resto del kernel.Questo rende lo sviluppo poco coerente con problemi evidenti sia tecnici,sia pratici per gli sviluppatori e per l’utente finale.
Credo che ZFS possa esser integrato tranquillamente nel kernel a patto che le modifiche siano private e quindi ne sia vietata la redistribuzione.
Se queste problematiche sono “fumo” allora ne sono accecato.
Concludendo il mio intervento,credo che i problemi dell’informatica di oggi non siano risolvibili usando senza logica la GPL _ovunque_ bensi’ eliminando il sistema malato dei brevetti che crea monopoli artificiali e l’obbligo di standard e formati aperti.Al resto diamo piena liberta’ a chiunque di fare cio’ che vuole.
Il problema non sta a valle bensi’ a monte.
sherpya
29 lug 2010 - 11:27 - #6saro’ ignorante ma una cosa ancora non l’ho capita, su linux esistono i moduli closed e zfs non va bene?
Cesoia
29 lug 2010 - 11:47 - #7Il sistema GPL alla fine,non sta facendo altro che creare un mondo alternativo ed ermentico al software proprietario,tradendo nei fatti l’apertura che lo contraddistingue.Se ci sono dei problemi nell’informatica attuale li si devono risolvere dal di dentro,non contrapponendosi,dal di fuori e girandoci intorno.Anche perche’ cosi’ si rischia di non arrivare da nessuna parte.Di non raggiungere nessun obiettivo.Non serve reinventare la ruota ma va preso cio’ che andava bene e si risolvono le vecchie criticita’.
Il software opensource e’ concepito oggi,come sistema a se’,come alternativa e per molti come anomalia.Non e’ parte integrante delle realta’ commerciali tradizionali.
Fidatevi non abbiamo bisogno della GPL per creare qualcosa di diverso ma abbiamo bisogno di riaggiustare il vecchio,combattendo il sistema distorto dei brevetti,degli standard e formati proprietari.Il resto viene da se’.
Cesoia
29 lug 2010 - 11:49 - #8@sherpya
Le modifiche estese necessarie al kernel linux non rendono ZFS un semplice modulo closed.
Nedanfor
29 lug 2010 - 16:16 - #9@Cesoia
“Il sorgente non e’ un diritto del consumatore”
Errato, è mio DIRITTO poter sapere cosa fa un programma. Ed è un dovere delle PA usare programmi liberi* (non solamente opensource), per la sicurezza di noi cittadini e perché i programmi in questo modo sono estensibili e modificabili, non sarà necessario affidarsi ad una sola azienda. Perché? E se l’azienda chiudesse? Bisognerebbe fare un esoso piano di conversione. E se l’azienda volesse alzare i prezzi? Pagheremmo tutto di tasca nostra. Credo sia palese che questo non dovrebbe essere possibile.
*E ben documentati, mi sento di aggiungere. Magari anche fatti sviluppare ad-hoc dall’UE per gli stati membri.
—
ZFS su *BSD è sperimentale, inutile fare benchmark. Quanto a ZFS vs Btrfs per ciò che riguarda le funzionalità: provate ambedue i filesystem e ditemi dov’è il paragone.
Cesoia
29 lug 2010 - 19:57 - #10@Nedafor
“Errato, è mio DIRITTO poter sapere cosa fa un programma. ”
Certo che e’ un diritto sapere cosa fa un programma,ma il suo sorgente non e’ un DIRITTO.Sono due cose differenti.
“Ed è un dovere delle PA usare programmi liberi* (non solamente opensource), per la sicurezza di noi cittadini e perché i programmi in questo modo sono estensibili e modificabili, non sarà necessario affidarsi ad una sola azienda.”
E’ obbligo non solo delle PA ma di tutto il software,legarsi a standard aperti e formati aperti per valutare quando lo si desidera,le migliori offerte senza vincolo alcuno.
Il sorgente anche in questo caso e’ inutile poiche’ nel momento in cui si usano protocolli,API ben documentate sviluppare soluzioni in proprio non e’ un problema.
Non serve obbligare al sorgente se vi e’ cooperazione attraverso la standarizzazione.Con la standarizzazione hai l’indipendenza quindi non serve aggiungere altro.
Meglio che Stallman bussi alla porta anche di Autodesk ogni tanto……
sherpya
29 lug 2010 - 21:20 - #11beh spero che btrfs si stabilizzi (ma non c’e’ pure li oracle? :D)
siamo rimasti veramernte dietro su linux,
ultimamente sto usando anche xfs, ma guardate zfs l’ho provato
su sparc e’ un altro pianeta, non parlo di performance ma di come funziona
e’ tutto un altro concetto. Ext3 e decisamente lento, ext4 non so ma a questo punto e’ un ext3 anabolizzato con gli extent
Nedanfor
31 lug 2010 - 14:53 - #12@Cesoia
Beato tu che ti fidi del primo che passa. Io grazie al cielo sono sono così incline al cercami trojan… Standard aperti e formati aperti va bene, programma chiuso non va bene. Prendi Microsoft Office: dice di supportare ODF. Potendo leggere e modificare il codice potresti implementarlo (o farlo implementare) realmente, così com’è invece hai un prodotto non funzionante… e se la Microsoft ci avesse aggiunto uno spyware all’interno tu non te ne accorgeresti mai.