Della storia e delle possibili cause di ZFS ne abbiamo parlato un paio di giorni fa. Jeff Bonwick (leader del progetto ZFS di Sun) conferma (senza entrare nel dettaglio) le voci sull’uscita di Apple dal progetto:

> Apple can currently just take the ZFS CDDL code and incorporate it
> (like they did with DTrace), but it may be that they wanted a “private
> license” from Sun (with appropriate technical support and
> indemnification), and the two entities couldn’t come to mutually
> agreeable terms.

I cannot disclose details, but that is the essence of it.

Sembrano anche confermati i motivi ipotizzati precedentemente (dal blog di Louis Gerbarg):

Now, some people jump may comment that it couldn’t be licensing issues, since ZFS is opensource (under the CDDL), and that Apple already uses CDDL software (DTrace). That may be true, but [...] there is more [...] than that. Apple may have wanted guarantees of indemnification in the NetApp lawsuit. Maybe it wanted guarantees that certain modifications it wanted to make would be accepted upstream, or even to get Sun to make certain changes. It also might have wanted additional distribution rights that were not granted under the CDDL.

Insomma il motivo principale sembra essere proprio la causa (la seconda) intentata da NetApp nei confronti di Sun riguardo alcune violazioni di brevetti. Non essendoci rassicurazioni (legalmente parlando) circa le possibili conseguenze Apple avrebbe quindi preferito uscire dall’implementazione.

Lasciando da parte il discorso su ZFS e il suo reale potenziale alla fine la scelta di Apple può comunque essere condivisibile.
Il problema dello sviluppo di un file system riguarda i sui cicli di sviluppo che sono generalmente molto più ampi rispetto a quelli sull’aggiornamento di un OS. Questo potrebbe essere un problema in Apple dove generalmente i team di ingegneri sono più piccoli e dovrebbero seguire il progetto per più tempo. In questo senso la scelta di ZFS era sicuramente la via che avrebbe comportato un buon equilibrio tra lavoro da svolgere (sicuramente minore) e qualità del prodotto (sebbene non perfetto ZFS rimane sicuramente un eccellente esempio di FS).

Per quanto già detto sopra comunque la scelta di ZFS è stata ad oggi abbandonata da Apple. In ogni caso, anche se Sun definisce ZFS come “The Last Word in Filesystems” (un bel gergo markettaro come siamo stati abituati da tutte le compagnie dell’IT, Apple inclusa) ci sono almeno 3 buoni motivi per cui Apple potrebbe comunque trarre vantaggio da una situazione oggi poco gradevole:

• Ad oggi si sono fatti diversi passi avanti in alcune tecnologie chiave che potrebbero semplificare lo sviluppo di un nuovo FS. Sto parlando dei B-Trees, Shadowing e Clones (per i più curiosi qui un PDF, parecchio tecnico). Queste tecnologie sono state la base per l’inizio del progetto BtrFS, un nuovo FS che condivide con ZFS diverse idee di base, ma che contiene una implementazione interna totalmente diversa (per i più curiosi qui un confronto tra i due, scritto da Valerie Aurora che ha lavorato per diverso tempo su ZFS in Sun).
• ZFS è stato disegnato per dispositivi di storage con un’interfaccia che oggi è vecchia di 10 anni. Parlo soprattuto della tecnologia a stato solido (SSD) che andrà con gli anni a venire a sostituire i vecchi dischi rotanti. In questo ambito alcuni comportamenti chiave di ZFS sono stati adattati proprio alle caratteristiche dei vecchi dischi (in verità ZFS contiene alcune ottimizzazioni in tal senso ma è normale che queste siano derivazioni e non il punto focale dello sviluppo ).
• Ultimo ma non ultimo il target di riferimento per ZFS. Trattasi di un filesystem creato per lavorare su grandi sistemi che contengono diverse unità. Tra le conseguenze va considerato anche il fatto che ZFS richiede una grande quantità di RAM. NEC tempo fa si occupò del porting di ZFS su processori ARM ma decise di abbandonare il progetto; si riuscì ad arrivare ad un consumo di 8MB (anche 2MB ma si andò incontro a incompatibilità di formato); se questo può essere influente su un sistema desktop è comunque considerabile su dispositivi di piccola taglia (anche se ultimamente anche questi stanno vedendo una crescita esponenziale sulle caratteristiche).

In definitiva il più grande problema che Apple dovrà affrontare nella stesura di un nuovo FS sarà il tempo necessario al ciclo di sviluppo.

Un altro problema è quello sollevato da Wolf sul suo twitter:

“[...]it’s so sad. Now we’ll have an Yet Another Incompatible Nextgen File System”

Problema innegabile ma che potremmo anche ignorare. Partiamo dal presupposto che lo storage quotidiano può essere diviso in due grosse categorie: quello che gli utenti tengono sul loro computer (su cui generalmente non fa differenza di compatibilità cosa si usa) e quello che gli utenti utilizzano per scambiare i dati col mondo esterno (ex. chiavette USB). Questo significa che l’uso di ZFS o di un altro filesystem nello storage interno (magari creato in Apple) non porterà ad insormontabili problemi di compatibilità (è vero, ci sono sempre quei computer con partizioni multiple, ma si tratta comunque di casi sporadici e risolvibili, comunque non degni di una considerazione così grande).

Un altro punto importante per il successo di un filesystem è la sua semplicità. Pensate alle compatte digitali, dispositivi abbastanza semplici che non richiedono feature come snaphost o supporto a più drive; certamente si potrebbe usare qualcosa di più evoluto che non FAT32, ma è anche vero che la risposta non è certo in ZFS. In altre parole nei dispositivi utilizzati come driver esterni la risposta non può essere ZFS (ma serve qualcosa di semplice, la cui implementazione in sola lettura sul firmware non richieda tempi di sviluppo elevati), mentre nei dischi di storage interno non ha (fondamentalmente) importanza se il tipo di implementazione è compatibile o meno con l’esterno. Questo è più o meno il comportamento di Microsoft che utilizza NTFS per i dischi interni e FAT32 per i dispositivi di interscambio.