Ubuntu 16.04 LTS e ZFS

[hashbang]

Il 16 Febbraio Canonical ha annunciato che Ubuntu 16.04 LTS integrerà nativamente ZFS e lo utilizzerà come back-end per i container gestiti tramite LXD.

Ebbene, la mossa sembra che stia causando non poche perplessità (sono intervenuti addirittura Lennart Poettering, Matthew Garrett ed Alan Cox): dai possibili problemi di licenza tra la Common Development and Distribution License (CDDL) e la GNU General Public License (GNU GPL) - motivo storico della mancata inclusione di ZFS in Linux - al motivo per il quale Canonical non abbia scelto BTRFS come file system di riferimento, specie considerando la sua integrazione con machinectl (systemd).

Ma vediamo un po' più nel dettaglio qual è l'incompatibilità tra la GNU GPL e la CDDL e perché ZFS non può quindi essere integrato direttamente nel kernel Linux.
La CDDL è una licenza che deriva dalla Mozilla Public License (MPL) ed è simile alla GNU LGPL, salvo il fatto che ha un copyleft debole che si applica solo ai file rilasciati sotto tale licenza e non all'intero progetto.
Il che significa che è possibile espandere il prodotto rilasciato sotto licenza CDDL e rilasciarlo come closed source, limitandosi a rilasciare i sorgenti della sola parte CDDL.
Il rilascio di tale parte rimane naturalmente obbligatorio, così come il rispetto di tale licenza. Ma come ho scritto prima, si limita solo ai FILE già rilasciati.

Questo rende impossibile all'atto pratico un mix con la GNU GPL che invece impone che non ci siano "limitazioni" di questo tipo per evitare espansioni closed source di software open, mentre invece sarebbe stato possibile se il codice fosse stato rilasciato sotto BSD, in quanto quest'ultima permette la redistribuzione di tutto il codice sotto diversa licenza, cosa già avvenuta in passato e che - a dirla tutta - ha attirato non poche critiche dal mondo BSD, che si è visto impossibilitato nel prendere le migliorie apportate da Linux al codice originario.

Questo cosa vuol dire all'atto pratico? Beh, vuol dire che non potremo mai vedere ZFS nel trunk del kernel Linux.
Tuttavia non vuol dire che ZFS non possa essere portato da noi. Il porting infatti è stato fatto sia via FUSE (zfs-fuse, che se non ricordo male è defunto da tempo) e sia tramite modulo nativo nel progetto ZFSonLinux.

Tutto ciò che non si deve fare è unirli nel kernel e distribuire il tutto come un blocco unico. Tuttavia, non è affatto vietato pacchettizzare ZFS e distribuirlo nella propria distro come modulo a sé.

Ora, al di là della questione legale, che pare sia stata già affrontata dagli avvocati di Canonical:

Our lawyers have examined the licenses in detail and we see no problem. ZFS remains CDDL and the kernel GPL. zfs.ko ships add a kernel module.

sebbene in molti abbiano fatto notare che ZFS sia effettivamente nello stesso trunk del kernel Linux, e sebbene nella wiki di Ubuntu gli accenni al conflitto di licenza tra CDDL e GPL siano stati "misteriosamente" eliminati dallo stesso Kirkland.

(EDIT: A tal proposito sembra che la storia non sia destinata a finire tanto facilmente)

Quello che IMHO traspare da questa mossa è una manovra anti-Red Hat per cercare di catturare l'attenzione di sysadmin Solaris, notoriamente affezionati a ZFS e spesso avversi a BTRFS.
In sostanza è come se Canonical IMHO stesse cercando di dire: "ehi, gente: state scappando da Oracle e dai suoi contratti di licenza assurdi? Beh, non c'è più bisogno di disperarsi. Anche se Linux non è Solaris, noi vi offriamo un completo supporto a ZFS sui vostri container."

Questa sensazione è data dal modo in cui viene presentata la cosa

ZFS one of the most beloved features of Solaris, universally coveted by every Linux sysadmin with a Solaris background. To our delight, we're happy to make to OpenZFS available on every Ubuntu system.

Dato che Ubuntu Server, sebbene sia uno dei big player per quanto riguarda OpenStack, non può facilmente scardinare il dominio di Red Hat Enterprise Linux, allora cerca di far breccia in coloro che stanno lasciando le lande Oracle.

Una mossa sicuramente astuta, ma che rischia di distruggere ancora di più la già precaria reputazione di BTRFS, che dopo 9 anni di sviluppo non è riuscito a guadagnarsi lo stesso rispetto che l'IT nutre per il suo rivale, specialmente a causa del suo diverso design che lo ha portato a diverse limitazioni, tra cui la mancanza di una gestione seria delle opzioni di montaggio dei subvolumi rispetto alle properties dei dataset ZFS, mancanza della gestione dei block device (ZVOL in ZFS) che permettono di eliminare completamente l'uso di LVM, deduplicazione on-line integrata, nessuna integrazione con NFS e CIFS, e specialmente col primo attraverso il supporto al mixed case, case insensitive e ACL NFSv4/Windows NT ed il non essere a 128-bit.
Senza contare che BTRFS si è visto privato del supporto da parte dell'azienda che l'ha creato, Oracle, che ha stipendiato Chris Mason (ideatore e team leader di BTRFS) fino a qualche anno fa, per poi vederlo lasciare la compagnia dopo l'acquisizione di SUN e l'offerta di soluzioni storage totalmente ottimizzate per ZFS.
Ora, naturalmente BTRFS ha molti altri partner, tra cui Red Hat, Fujitsu (che tra l'altro sviluppa i processori SPARC insieme ad Oracle su cui poi ci fanno girare Solaris 11 e ZFS ), Intel ecc., ma rimane comunque il fatto che questo file system stia venendo trattato come seconda scelta. E la mossa di Canonical potrebbe rischiare veramente di decretarne il fallimento, se la combinazione ZFS+LXD si dovesse rivelare un successo.

[brg]

La mossa di Canonical è puramente commerciale, come molte mosse di Canonical, e credo che avrà ben poche ripercussioni sul futuro di BTRFS. Canonical sta solo cercando di occupare una fett(in)a di mercato, nell'attesa che BTRFS diventi il filesystem di riferimento, un po' come hanno fatto con Upstart e Systemd o come stanno già facendo con MIR e Wayland. Dopotutto, a parte i discorsi, ZFS è un filesystem molto di nicchia, solamente Solaris ed i BSD lo usano, mentre BTRFS è la nuova (ormai vecchia...) promessa con il supporto delle grandi corporazioni che usano grandi infrastrutture server, da Facebook a Google. Proprio a Facebook Chris Mason è impiegato per lavorare su BTRFS: http://lkml.iu.edu/hypermail/linux/kern ... 03510.html. BTRFS è il filesystem con più supporto corporativo al momento, magari in un prossimo futuro salterà fuori un altro FS che lo soppianterà nei cuori delle corporazioni, ma questo non sarà di certo ZFS.

[hashbang]

Beh, che sia una mossa chiaramente commerciale lo penso anch'io. Come ho detto: sta strizzando l'occhio ai clienti insoddisfatti di Oracle.

Che sia una piccola fetta di mercato, dubito, onestamente. Canonical non è inesistente nel settore server, ma anzi: possiamo anche azzardare che è il più grosso player del cloud Linux in circolazione. E con una quota in forte crescita. Di clienti grossi che fanno contratti ne ha. L'ultima in ordine di tempo è AT&T.
La differenza tra Canonical e Red Hat sta nel fatto che la seconda ha come core business per lo più contratti già stipulati in passato, mentre Canonical sta andando a rosicchiare le quote di UNIX e Windows Server.
Però già come cloud, Ubuntu è una presenza piuttosto forte. Su Azure è considerata la distro Linux numero 1 in termini di deploy. Juju, tecnologia chiave di Ubuntu Server, ha riscosso parecchio successo tra i clienti di Canonical. Senza contare che questa investe sul cloud da molto più tempo di Red Hat. Red Hat è saltata sul carro di OpenStack quando esso era già una realtà, mentre Canonical ha cominciato prima con Eucalyptus su Jaunty e poi è passata ad OpenStack poco dopo, quando era ancora agli inizi.

Poi, per quanto riguarda l'aspettare BTRFS, beh, onestamente non paragonerei mai questo file system a systemd.
systemd aveva ed ha tuttora dei suoi meriti ed ha giocato in un campo dove non c'erano affatto alternative, da nessuna parte. BTRFS non ha meriti, se non la possibilità di comprimere facilmente dati che non sono stati compressi per via del CoW, ma per il resto è completamente un mondo a sé. La stessa Red Hat che da un lato lo integra in systemd se ne sta stando ben alla larga per ora, ed è stata la stessa azienda che l'ha definito broken by design.
Dopotutto, parliamoci chiaro. Sono 9 anni che viene sviluppato e dietro di lui - come hai giustamente detto tu - ci girano molti soldi. Sicuramente ci stanno girando molti più soldi di quanti ne abbia mai investiti SUN in ZFS. D'altronde basti pensare che la deduplicazione è arrivata a fine 2008/inizio 2009, quindi con l'azienda al collasso e l'acquisizione alle porte. Eppure in 9 anni (dal 2001 al 2010) ZFS era già diventata una realtà molto apprezzata in produzione.
BTRFS continua a non convincere, e IMHO non convincerà mai. Per come la vedo io è un fallimento che aspetta solo di essere deprecato in favore di qualcos'altro. Ed è questo il problema: i clienti non vogliono usare una soluzione per poi deprecarla poco dopo solo perché su Linux gli ingegneri non sanno sviluppare un file system. Questo è grave. E c'è tanta gente là fuori che andrebbe dal primo produttore che gli offrisse un supporto commerciale a ZFS su Linux. E Canonical questo lo sa.
BTRFS continua a non avere una policy precisa per il formato. Non c'è ancora un modo sicuro per gestire il formato del file system, e ancora oggi c'è il rischio di ritrovarsi con un volume non montabile se si usa una versione precedente. Ed il fatto che dopo 9 anni lo utilizzino molte poche compagnie rispetto alla presenza Linux la dice lunga.

[lablinux]

Non sono fan Ubuntu anche se apprezzo Unity e a mia personalissima esperienza non ho mai avuto grattacapi o blocchi di sistema.
Detto ciò, trovo una buona mossa zfs se questo avvicina più persone a Linux.

Canonical, oltre a fare azioni commerciali, sta cercando uno spazio suo senza dover fare i conti con continui 'sbalzi di umore' della comunità Opens Source.
MIR su tutti, perché non ha voluto seguire wayland? wayland è rimasto nel cassetto per anni e lo sviluppo andava a rilento, mentre canonical voleva portare a casa un nuovo server per gestire la grafica. Ha iniziato con MIR, et voilà, lo sviluppo di wayland è magicamento ripartito.

Ora due statistiche dei server web:
http://w3techs.com/technologies/details/os-unix/all/all
http://w3techs.com/technologies/details ... ux/all/all
http://w3techs.com/technologies/details ... tu/all/all

purtroppo /os-slackware/ dice page not found....

[hashbang]

Ora, al di là della questione legale, che pare sia stata già affrontata dagli avvocati di Canonical:

Our lawyers have examined the licenses in detail and we see no problem. ZFS remains CDDL and the kernel GPL. zfs.ko ships add a kernel module.

sebbene in molti abbiano fatto notare che ZFS sia effettivamente nello stesso trunk del kernel Linux, e sebbene nella wiki di Ubuntu gli accenni al conflitto di licenza tra CDDL e GPL siano stati "misteriosamente" eliminati dallo stesso Kirkland.

(EDIT: A tal proposito sembra che la storia non sia destinata a finire tanto facilmente)

Naturalmente è arrivata la conferma che molti si aspettavano.

Ora, onestamente qui ha sbagliato in pieno Canonical.
ZFS NON può essere distribuito all'interno del kernel Linux perché equivale a combinare due lavori che si trovano sotto due licenze incompatibili fra loro.
L'unico modo per raggirare il conflitto, e quindi la GNU GPL, permettendo così di implementare ZFS su Ubuntu è quello di fornire un pacchetto SEPARATO per il modulo.
Canonical invece ha messo sia il kernel che il driver di ZFS all'interno dello stesso pacchetto linux-image. Questo è un darsi la zappa sui piedi da soli.
Se avessero distribuito ZFS separatamente la SFC non avrebbe potuto dire nulla al riguardo perché prima di dare dell'illegale a ZFS avrebbe dovuto darlo alle distro che distribuiscono i driver nvidia nei loro repository, che essendo closed source sono in una situazione addirittura peggiore.

[Meskalamdug]

Detto ciò, trovo una buona mossa zfs se questo avvicina più persone a Linux.

Vero
Oltretutto è un ottimo fs

[hashbang]

Ed anche Debian integra ZFS, sebbene in forma di sorgente compilabile tramite DKMS.

[hashbang]

Poi, per quanto riguarda l'aspettare BTRFS, beh, onestamente non paragonerei mai questo file system a systemd.
systemd aveva ed ha tuttora dei suoi meriti ed ha giocato in un campo dove non c'erano affatto alternative, da nessuna parte. BTRFS non ha meriti, se non la possibilità di comprimere facilmente dati che non sono stati compressi per via del CoW, ma per il resto è completamente un mondo a sé. La stessa Red Hat che da un lato lo integra in systemd se ne sta stando ben alla larga per ora, ed è stata la stessa azienda che l'ha definito broken by design.
Dopotutto, parliamoci chiaro. Sono 9 anni che viene sviluppato e dietro di lui - come hai giustamente detto tu - ci girano molti soldi. Sicuramente ci stanno girando molti più soldi di quanti ne abbia mai investiti SUN in ZFS. D'altronde basti pensare che la deduplicazione è arrivata a fine 2008/inizio 2009, quindi con l'azienda al collasso e l'acquisizione alle porte. Eppure in 9 anni (dal 2001 al 2010) ZFS era già diventata una realtà molto apprezzata in produzione.
BTRFS continua a non convincere, e IMHO non convincerà mai. Per come la vedo io è un fallimento che aspetta solo di essere deprecato in favore di qualcos'altro. Ed è questo il problema: i clienti non vogliono usare una soluzione per poi deprecarla poco dopo solo perché su Linux gli ingegneri non sanno sviluppare un file system. Questo è grave. E c'è tanta gente là fuori che andrebbe dal primo produttore che gli offrisse un supporto commerciale a ZFS su Linux. E Canonical questo lo sa.
BTRFS continua a non avere una policy precisa per il formato. Non c'è ancora un modo sicuro per gestire il formato del file system, e ancora oggi c'è il rischio di ritrovarsi con un volume non montabile se si usa una versione precedente. Ed il fatto che dopo 9 anni lo utilizzino molte poche compagnie rispetto alla presenza Linux la dice lunga.

Pare che sia andata esattamente come avevo previsto.
Anche Red Hat sta abbandonando BTRFS, lasciando praticamente solo SUSE come player ad aver portato questo FS in produzione nei suoi sistemi.

[brg]

Anche Red Hat sta abbandonando BTRFS, lasciando praticamente solo SUSE come player ad aver portato questo FS in produzione nei suoi sistemi.

SUSE e Oracle per la precisione. Oracle che peraltro ha finito di smantellare la sua squadra di sviluppatori ZFS.

La questione in realtà è un po' più complessa. Ora Oracle è una delle principali forze dietro a BTRFS e Oracle Linux è basato su Red Hat: è probabile che Red Hat voglia differenziare la propria offerta da quella di Oracle proponendo una soluzione diversa, cioè XFS con Stratis. Potrebbe esserci inoltre quello che dice un ex sviluppatore di Red Hat, ovvero che per Red Hat fornire BTRFS costerebbe molto, in quanto si tratta di un prodotto che si evolve tuttora molto rapidamente e quindi ha bisogno di una squadra di sviluppatori per contribuire il codice nuovo e per occuparsi dei backport. Red Hat preferisce investire in soluzioni più mature, che però non sono ZFS. Da tutta questa storia quello che emerge è che ZFS non è nemmeno un'opzione.

[hashbang]

SUSE e Oracle per la precisione. Oracle che peraltro ha finito di smantellare la sua squadra di sviluppatori ZFS.

Gli ingegneri di ZFS non sono mai stati in Oracle, tanto per cominciare, se escludiamo Darren Moffat. Tutti quanti sono sotto OpenZFS che è l'implementazione de facto. Chi era rimasto in Oracle erano giusto le scimmie da codice, ma quelle le raccatti al supermercato in offerta per quante ce ne sono.
Oracle ZFS è legato a Solaris, che è in fase di dismissione, ed ha un bacino d'utenza molto ristretto, oltre al non aver subito evoluzioni sostanziali dall'acquisizione di SUN.
Se parliamo di ZFS parliamo di OpenZFS, che ha dietro colossi come Intel.

La questione in realtà è un po' più complessa. Ora Oracle è una delle principali forze dietro a BTRFS e Oracle Linux è basato su Red Hat: è probabile che Red Hat voglia differenziare la propria offerta da quella di Oracle proponendo una soluzione diversa, cioè XFS con Stratis.

Differenziare la propria offerta creando un superset in userspace scritto in Python+Rust che combini LVM+XFS+altro, aggiungendoci qualche API qua e là per integrarlo lato applicativo, e cercare di raggiungere una parità di funzioni con ZFS (parole di Red Hat)? E gli snapshot CoW? Vogliamo usare quelli di LVM che non c'entrano nulla con ZFS?
O il send/recv? Ma sì, che ci importa, tanto basta il copia-incolla di qualche immagine Docker qua e là ed è fatto, no?
Ed i subvolumi? Creiamo un VG con LVM, mettiamo su volumi logici e facciamo finta che siano la stessa cosa.
Ed il self-healing? Continuiamo ad andare avanti a colpi di fsck nel 2017. Così rimaniamo anche legati alla tradizione.
E la dedup? E la compressione? Ma sì, al limite facciamo substrati come ha fatto Microsoft con Storage Spaces o ci affidiamo a qualche pessima soluzione su FUSE.

Se questo è l'intento che vogliono raggiungere, stiamo freschi. Il non plus ultra del vecchiume riciclato, tirato a lucido e spacciato per nuovo.

Pensavo che nessuno potesse fare peggio di Microsoft con Storage Spaces+ReFS, ma pare che mi sia sbagliato. In sostanza abbiamo atteso dieci anni per un'alternativa a ZFS ed il massimo che siamo riusciti a ricevere è una utility e un demone basato su DBus. Caspita!

Potrebbe esserci inoltre quello che dice un ex sviluppatore di Red Hat, ovvero che per Red Hat fornire BTRFS costerebbe molto, in quanto si tratta di un prodotto che si evolve tuttora molto rapidamente e quindi ha bisogno di una squadra di sviluppatori per contribuire il codice nuovo e per occuparsi dei backport.

brg, andiamo, su.
Poteva tranquillamente assumere, come fanno tutti. Se aveva veramente interesse nel portare avanti la tecnologia, si portava il know-how in casa, come ha fatto sempre. Ma non l'ha fatto, quindi a mio avviso è quanto mai evidente che non c'era la volontà di investire da parte loro.
Ma non gliene faccio una colpa, io lo sapevo già che sarebbe finita così. L'avevo praticamente detto un anno fa:

La stessa Red Hat che da un lato lo integra in systemd se ne sta stando ben alla larga per ora, ed è stata la stessa azienda che l'ha definito broken by design.

Red Hat preferisce investire in soluzioni più mature, che però non sono ZFS.

Questa è una frase che fa sorridere, se pronunciata da gente che ha cambiato tre init in tre release, di cui l'ultimo che è stato integrato sebbene avesse ancora problemi di gioventù, con tanto di bug gravi avvenuti in produzione segnalati sul loro bugzilla.
E pensa quanto sarà divertente se faranno la stessa cosa lato storage. Già me li vedo i sysadmin a cambiare la loro infrastruttura ogni volta che Red Hat impazzisce e cambia le carte in tavola.
Tra l'altro non può proporre ZFS così facilmente. Sarebbe stato un autogol clamoroso, dopo aver messo in piedi tutto quel teatrino su Canonical.

Ma al di là di tutto, questo è sostanzialmente quello che ho detto io un anno fa.

BTRFS continua a non convincere, e IMHO non convincerà mai. Per come la vedo io è un fallimento che aspetta solo di essere deprecato in favore di qualcos'altro. Ed è questo il problema: i clienti non vogliono usare una soluzione per poi deprecarla poco dopo solo perché su Linux gli ingegneri non sanno sviluppare un file system. Questo è grave. E c'è tanta gente là fuori che andrebbe dal primo produttore che gli offrisse un supporto commerciale a ZFS su Linux. E Canonical questo lo sa.
BTRFS continua a non avere una policy precisa per il formato. Non c'è ancora un modo sicuro per gestire il formato del file system, e ancora oggi c'è il rischio di ritrovarsi con un volume non montabile se si usa una versione precedente. Ed il fatto che dopo 9 anni lo utilizzino molte poche compagnie rispetto alla presenza Linux la dice lunga.

Da tutta questa storia quello che emerge è che ZFS non è nemmeno un'opzione.

No, da questa storia emerge un classico problema di Linux: in segmenti critici non si sa innovare e nemmeno copiare. E ce ne sono altri di esempi che possiamo citare. Chi ha avuto un briciolo di furbizia, ha investito su tecnologie mature come ZFS e se l'è portate in casa. Chi invece è affetto dalla sindrome del NIH ha cercato di rifare la tecnologia senza riuscirci per poi deprecarla qualche anno dopo facendo finta che nulla fosse successo.

[brg]

Be', non è che voglia ripetermi, ma la mossa di Red Hat, come già quella di Canonical, è soprattutto politica e non avrà significative ripercussioni sul futuro di BTRFS. Soprattutto considerato il fatto che Red Hat aveva deciso di puntare su XFS già nel 2012 ed ora, probabilmente, sono semplicemente diventati maturi i tempi per il loro Stratis. Tuttavia la soluzione di Red Hat appare come una toppa (come Upstart o MIR per Ubuntu) e non ci sono molti dubbi che in un futuro non molto lontano, pure loro dovranno ripiegare su qualcos'altro: lo stesso BTRFS o un nuovo file-system che deve ancora nascere e che avrà molte delle caratteristiche di BTRFS.