Recentemente è emerso un grave problema in OpenZFS 2.2.0, implementato in sistemi operativi come FreeBSD 14. La nuova funzionalità, introdotta un mese fa, si chiama “clonazione di blocchi” e mira a ottimizzare la gestione dei dati. Tuttavia, un bug critico, identificato dal team di Gentoo e segnalato come bug #15526, ha portato al rilascio immediato di OpenZFS 2.2.1, che temporaneamente disabilita questa funzione.
Questo incidente solleva preoccupazioni riguardo all’affidabilità di OpenZFS, noto per la sua robustezza e integrità dei dati. Inoltre, per sistemi come FreeBSD 14, che includono questa versione di OpenZFS, si raccomanda cautela. Colin Percival, esperto BSD, ha sottolineato su Twitter che la funzionalità “clonazione di blocchi” è disattivata di default in FreeBSD 14 e ha avvertito di non attivarla per evitare la perdita di dati.
Il bug si manifesta come corruzione di file – i file copiati mostrano una combinazione di zeri e blocchi di dati che sembrano codificati in Base64. Interessante è che i controlli di salute del file system non rilevano il problema, un aspetto che richiede attenzione.
La natura del bug sembra essere legata a circostanze specifiche e rare. Bronek Kozicki ha spiegato su GitHub che il bug potrebbe verificarsi durante la scrittura asincrona di un file, se in quel preciso momento si legge la parte del file che sta ancora venendo scritta. Questo può portare a dati corrotti, un problema non facilmente rilevabile senza confrontare i checksum.
Gli sviluppatori hanno identificato un problema correlato ai dnode di ZFS e alla loro gestione, che potrebbe essere un bug più antico e nascosto. Il bug è diventato più evidente con l’introduzione della nuova funzionalità di clonazione dei blocchi, soprattutto in sistemi con multi-core.
Per gli utenti Linux, sembra che il bug sia correlato anche alla versione di coreutils utilizzata, in particolare versioni successive alla 9.x. Non è ancora chiaro se Ubuntu 23.10 abbia attivato di default questa funzione nel suo supporto ZFS, che è recentemente ritornato ma ancora sperimentale.
Ci si aspetta che OpenZFS 2.2.2 arrivi presto per risolvere questi problemi. Nel frattempo, la community è invitata a mantenere un approccio cauto e a considerare backup su altri file system per garantire la sicurezza dei dati.
Abbiamo già menzionato il lavoro dell’esperto BSD Colin Percival, ma chiunque abbia già installato questa release “punto zero” dovrebbe prestare attenzione al suo avvertimento su Twitter X: “Il codice ZFS di FreeBSD 14 supporta la ‘clonazione di blocchi’. Questa è disattivata per impostazione predefinita. NON ATTIVARE QUESTA FUNZIONALITÀ SE NON VUOI PERDERE DATI.”
FreeBSD 14's ZFS code supports "block cloning". This is turned off by default.
DO NOT ENABLE THIS FEATURE UNLESS YOU WANT TO LOSE DATA. https://t.co/Embps7Te4e
— Colin Percival (@cperciva) November 23, 2023
Al momento della scrittura, non è chiaro esattamente cosa la causi. Sembra essere una combinazione di circostanze estremamente specifica (e quindi improbabile), il che significa che quasi mai si verifica, come spiega Bronek Kozicki su GitHub:
È necessario comprendere il meccanismo che causa la corruzione. Potrebbe essere presente da un decennio e causare problemi solo in scenari molto specifici, che normalmente non si verificano.
A meno che non si possa adattare il meccanismo di backup alle condizioni descritte di seguito, è molto improbabile essere stati colpiti da esso.
- Un file è in fase di scrittura (tipicamente in modo asincrono – il che significa che la scrittura non è completata al momento in cui il processo di scrittura “pensa” che lo sia)
- Nello stesso momento in cui ZFS sta ancora scrivendo i dati, la parte modificata del file viene letta. Lo stesso momento significa “colpire una finestra di tempo molto specifica”, misurata in microsecondi (un milionesimo di secondo).
- Se viene letto in questo momento molto specifico, il lettore vedrà zeri dove i dati scritti sono in realtà qualcos’altro
- Se il lettore poi memorizza gli zeri letti in modo errato da qualche altra parte, è lì che i dati vengono corrotti Uno dei cacciatori di bug ha scritto uno script, reproducer.sh, che colpisce i volumi ZFS e controlla se i file vengono corrotti. Uno dei problemi attorno a questa questione è che non c’è modo di scrivere un programma che possa segnalare se un file è stato corrotto o meno ispezionandone il contenuto: è perfettamente normale che alcuni tipi di file contengano lunghi tratti di zeri. L’unico modo per essere sicuri è confrontare i checksum prima e dopo le operazioni di copia – quindi gli utenti preoccupati che non dispongono di backup su altri tipi di file system non possono facilmente dire. Lo strumento integrato di OpenZFS per il controllo della validità dei pool di archiviazione non può rilevare il problema.
Una possibile correzione è aperta, e l’indagine sembra aver scoperto un bug sottostante, diverso e preesistente, che potrebbe essere stato presente già nel 2013. Il bug riguarda i dnode di ZFS e la logica di come il codice verifica se un dnode è “sporco” o meno, che governa se deve scaricarlo: sincronizzare eventuali modifiche sul disco.
È possibile che questa causa unica fosse profondamente nascosta, e quindi molto improbabile da colpire. Sfortunatamente, la nuova funzionalità di copia più veloce ha significato che ciò che era un bug che avrebbe solo corrotto i dati una volta ogni decine di milioni di copie di file, improvvisamente è diventato più probabile, specialmente su macchine con molti core di processore tutti in uso simultaneo.
Per gli utenti Linux, una condizione aggiuntiva sembra essere che il sistema operativo abbia una versione recente del pacchetto coreutils – sopra la versione 9.x. Questo è lo strumento che fornisce la funzionalità del comando cp. Finora, non siamo stati in grado di verificare se Ubuntu 23.10 abbia la funzione di clonazione dei blocchi abilitata per impostazione predefinita nel suo supporto recentemente ritornato (ma ancora sperimentale) per essere installato su ZFS, ma almeno un commento al bug originale è di qualcuno che lo ha riprodotto su Ubuntu.
Sembra molto probabile che OpenZFS 2.2.1, che semplicemente disattiva la clonazione dei blocchi, sarà rapidamente seguito da una release 2.2.2 per correggere il trattamento sottostante dei dnode.
