Ingrandisci / Linus Torvalds è eminentemente qualificato per discutere problemi con la compatibilità delle licenze e la politica del kernel. Tuttavia, ciò non significa che sia ugualmente qualificato per discutere di singoli progetti nel contesto specifico del progetto.
Lunedì scorso nel forum “Discussioni moderate” su realworldtech.com, Linus Torvalds, sviluppatore fondatore e attuale manutentore supremo del kernel Linux, ha risposto alla domanda di un utente su una controversia sulla manutenzione del kernel di un anno che ha avuto un forte impatto sul progetto ZFS su Linux. Dopo aver risposto alla vera domanda dell’utente, Torvalds ha continuato a fare affermazioni imprecise e dannose sul filesystem ZFS stesso.
Dato l’enorme peso attribuito automaticamente alle parole di Torvalds a causa del suo status di sviluppatore fondatore e capo manutentore del kernel Linux, riteniamo che sia una buona idea spiegare sia il controverso cambiamento del kernel stesso, sia i commenti di Torvalds sia sul cambiamento in questione che il file system ZFS.
Contents
La controversia originale del gennaio 2019, spiegata
Nel gennaio 2019, lo sviluppatore senior del kernel Greg Kroah-Hartman ha difeso ferocemente un commit del kernel Linux che disabilitava l’esportazione di alcuni simboli del kernel in moduli del kernel caricabili non GPL.
Per coloro a cui gira la testa, le esportazioni dei simboli del kernel espongono le informazioni interne sullo stato del kernel ai moduli del kernel caricabili. Il particolare simbolo discusso qui, _kernel_fpu_, tiene traccia dello stato dell’unità a virgola mobile del processore. Senza accesso a quel simbolo, i moduli del kernel esterni che accedono direttamente alla FPU, come fa ZFS, devono implementare il proprio codice di conservazione dello stato. La conservazione dello stato, sia all’interno del kernel che nativo dei moduli del kernel, assicura che lo stato originale dell’FPU venga ripristinato prima che il controllo venga rilasciato ad altro codice del kernel che potrebbe dipendere dai valori che hanno visto l’ultima volta nei registri dell’FPU.
L’impatto tecnico del rifiuto di continuare a esportare il simbolo _kernel_fpu_ non è impedire ai moduli di accedere direttamente alla FPU, ma solo impedire loro di utilizzare le funzionalità di gestione dello stato del kernel per preservare e ripristinare lo stato. La rimozione dell’accesso a quel simbolo richiede quindi agli sviluppatori di moduli di reinventare individualmente il proprio codice di conservazione dello stato. Ciò aumenta la probabilità di errori catastrofici all’interno del kernel stesso, poiché uno stato ripristinato in modo errato potrebbe causare l’arresto anomalo di un’operazione successiva del kernel.
La difesa di Kroah-Hartman della decisione di interrompere l’esportazione del simbolo nei moduli del kernel non GPL sembrava essere guidata in gran parte dal dispetto, come confermato dal suo stesso commento riguardo al cambiamento: “la mia tolleranza per ZFS è praticamente inesistente”. Normalmente, ZFS, su qualsiasi piattaforma, inclusi i BSD, utilizza l’ottimizzazione vettoriale SSE/AVX SIMD per velocizzare determinate operazioni. Senza l’accesso al simbolo _kernel_fpu_, gli sviluppatori ZFS sono stati inizialmente costretti a disabilitare completamente le ottimizzazioni SIMD, con un degrado delle prestazioni del mondo reale piuttosto significativo.
Annuncio
Sebbene il cambiamento, e il modo in cui Kroah-Hartmann lo ha difeso, abbia inizialmente generato molti drammi e incertezze, l’impatto a lungo termine sulla comunità Linux ZFS è stato piuttosto minimo. La modifica sostanziale ha interessato solo i kernel all’avanguardia che pochi utenti ZFS utilizzavano in produzione e nel luglio 2019 il nuovo codice di gestione dello stato nel modulo è stato inserito nell’albero dei sorgenti di ZFS su Linux.
“Non rompiamo gli utenti”
La posizione di Torvalds nel post sul forum di lunedì scorso inizia in modo ragionevole e ben informato, dopotutto è Linus Torvalds che discute del kernel di Linux. Nota che il famoso mantra del kernel “non rompiamo gli utenti” riguarda “letteralmente le applicazioni dello spazio utente” e quindi non si applica alla decisione di interrompere l’esportazione dei simboli del kernel in moduli del kernel non GPL. Per definizione, se stai cercando un simbolo del kernel, non sei un’applicazione in spazio utente. La linea che viene tracciata qui è molto brillante e funzionale: Torvalds sta dicendo che se vuoi girare nello spazio del kernel, devi stare al passo con lo sviluppo del kernel.
Da lì, Torvalds si dirama verso i problemi di licenza, un altro argomento su cui è accurato e ragionevole. “Onestamente, non c’è modo di unire nessuno degli sforzi ZFS fino a quando non ricevo una lettera ufficiale da Oracle”, scrive. “Altre persone pensano che possa essere OK unire il codice ZFS nel kernel e che l’interfaccia del modulo lo renda OK, e questa è una loro decisione. Ma considerando la natura litigiosa di Oracle e le domande sulle licenze, non c’è modo che io possa sentirmi al sicuro in così facendo.”
Continua discutendo la natura giuridicamente fragile del modulo del kernel “shim” utilizzato dal progetto ZFS su Linux (insieme ad altri progetti non GPL e non permissivi, come i driver grafici proprietari di Nvidia). C’è qualche dubbio sul fatto che costituiscano una difesa ragionevole ora, dal momento che nessuno ha contestato alcun progetto per l’utilizzo di uno shim LGPL per 20 anni e in esecuzione, ma in termini puramente logici, non c’è molto dubbio che gli shim non ottengano molto . La vera funzione di uno shim del modulo del kernel LGPL non è sanzionare il contatto con il kernel con codice non GPL, è proteggere il codice proprietario dall’altra parte dello shim dall’essere forzatamente pubblicato in caso di vittoria di una causa legale per l’applicazione della GPL.
Annuncio
Fin qui tutto bene, ma poi Torvalds approfondisce le proprie impressioni sullo stesso ZFS, sia come progetto che come filesystem. È qui che le cose vanno male fuori dai binari, come afferma Torvalds: “Non usare ZFS. È così semplice. È sempre stata più una parola d’ordine che altro, credo … [the] i benchmark che ho visto non fanno sembrare ZFS così eccezionale. E per quanto ne so, non ha più una vera e propria manutenzione dietro di sé…”
“È sempre stata più una parola d’ordine che altro”
Questa affermazione sbalorditiva mi fa chiedere se Torvalds abbia mai effettivamente usato o studiato seriamente ZFS. Tieni presente che non sta semplicemente facendo questa affermazione su ZFS ora, lo sta facendo su ZFS negli ultimi 15 anni e sta relegando tutto, dalle istantanee atomiche alla replica rapida, alla compressione su disco, al checksum per blocco, alla riparazione automatica dei dati e più allo stato di “solo parole d’ordine”.
C’è solo un altro filesystem ampiamente disponibile che prende anche una pugnalata rispettabile nel fornire la maggior parte di queste funzionalità, ed è btrfs, che non era disponibile per i primi anni di disponibilità generale di ZFS. In effetti, btrfs non è ancora abbastanza stabile per l’uso in produzione, a meno che non si nerf tutte le funzionalità che lo rendono interessante in primo luogo.
Il checksum per blocco di ZFS e la riparazione automatica dei dati hanno prevenuto molte volte la perdita di dati nel mio utilizzo nel mondo reale, incluso questo caso particolarmente eclatante di un controller SATA impazzito. Un mirror RAID1 standard avrebbe restituito allegramente quei 119 GB di dati errati senza alcun avviso, ma il checksum in tempo reale e il rilevamento degli errori di ZFS hanno mitigato il tutto al punto da non dover mai nemmeno toccare un backup.
Nel frattempo, gli snapshot atomici consentono di mantenere una copia identica completa dello storage blocco per blocco in un determinato momento con un sovraccarico delle prestazioni trascurabile e un sovraccarico di archiviazione minimo, e la replica di tali snapshot è in genere centinaia o migliaia di volte più veloce (e più affidabile) rispetto a soluzioni non integrate nel filesystem come rsync.
È possibile non avere un’esigenza personale per ZFS. Ma scriverlo come “più una parola d’ordine che altro” sembra esporre una massiccia ignoranza sull’argomento.
Ingrandisci / Sì, sono più di un MILIONE di blocchi che hanno restituito dati errati su un disco nel mirror e altri 18 sull’altro disco, solo per buona misura. “Nessun errore di dati noto.”
Jim Salter
