Contact me sending an e-mail (antispam defense activated)
Title: Cos'e` un journaling filesystem Author: Sandro Tosi Last modified: 2005-07-20 (2004-11-02) (2004-10-30) Si fa spesso molta confusione su cosa realmente sia un filesystem con funzionalita` journaling. Si ritiene, per esempio, che l'avere il journaling metta al riparo da riavvi improvvisi, rotture hardware, cataclismi... Un filesystem journaled non garantisce l'integrita` dei dati (non sempre) ma quella del filesystem stesso, che dovrebbe rimanere sempre integro (consistente) e quindi utilizzabile. Quasi tutti i sistemi operativi mantengono una cache del disco: dal momento che questo e` un supporto ad accesso lento, viene allocato in memoria Ram un buffer su cui vengono scritte le informazioni da aggiornare in seguito; raggruppando piu` operazioni di scrittura tra loro, si incrementano le prestazioni del sistema. In un filesystem vengono memorizzati due livelli di informazioni: i dati veri e propri, cioe` quelli che compongono i file, ed i ``metadati'', cioe` quei dati necessari al filesystem stesso per la sua gestione e per consentire l'accesso ai file (come inode, liste di riferimento, etc.). Le inconsistenze in un filesystem possono sorgere perche` vi erano dei dati da scrivere sul disco quando il sistema e` andato in crash. Alcune applicazioni potevano essere in fase di aggiornamento di alcuni file, oppure il filesystem stava aggiornando i propri metadati: mentre le inconsistenze nei dati sono gravi, in quanto non minano alla correttezza del filesystem, un'inconsistenza nei metadati e` quanto di peggio possa succedere ad un filesystem, un danno che puo` portare alla perdita di file, fino anche all'impossibilita` di utilizzo di tutto il filesystem. Al riavvio successivo al crash, il sistema operativo e` in grado di accorgersi che il filesystem non e` stato smontato correttamente: questo avviene grazie al ``dirty bit'', un bit nei dati di controllo del filesystem che viene impostato a 1 (o a 0, non ha importanza) quando viene montato, e poi a 0 (o 1) quanto si smonta il filesystem correttamente; se viene rilevato il dirty bit valorizzato ad 1, e` necessario eseguire un controllo di consistenza del filesystem, e tutti sappiamo quanto sia lento il fsck all'avvio... L'introduzione delle funzionalita` di journaling in un filesystem consiste nel mantenere un ``giornale'' (il journal, appunto) delle attivita` da svolgere sul filesystem, come i file da modificare con relativa posizione delle modifiche, quali file cancellare, e cosi` via. Cio` consente, in caso di riavvio improvviso della macchina, di poter controllare in questo log le ultime attivita` del filesystem ed effettuare un controllo in un tempo molto piu` breve. I database sono da tempo in grado di recuperare un guasto molto piu` rapidamente di un filesystem ``vecchio stampo'' in quanto utilizzano le transazioni: una transazione e` un insieme di singole operazioni che soddisfano alcune proprieta`, tra le quali la piu` importante ai nostri fini e` l'atomicita`. Garantire l'atomicita` di una transazione impone che tutte le operazioni inerenti questa transazione sono completate senza errori oppure cancellate, senza generare cambiamenti: una transazione non puo` essere eseguita parzialmente. I database traggono vantaggio da questo scrivendo in un file di log tutte le operazioni inerenti una transazione; non solo il nome dell'operazione, ma anche il contenuto degli argomenti prima dell'esecuzione dell'operazione. Dopo ogni operazione, deve essercene una di commit, che fa scrivere il buffer sul disco. In caso di crash, si puo` tracciare il log fino al primo commit statement, riscrivendo il contenuto precedenti degli argomenti nella loro posizione sul disco. Una differenza tra il journaling dei database e dei filesystem e` che quest'ultimi tendono a registrare solo le transazioni sui metadati: questa scelta consente di garantire l'integrita` e la coerenza della struttura del filesystem ma non la consistenza dei dati contenuti. In ogni caso, le probabilita` che i dati si corrompano risultano minori con una struttura del filesystem coerente. E` comunque possibile indicare (quasi sempre) di effettuare il journaling dei dati, a patto ovviamente che si sia pronti ad affrontare un calo delle prestazioni dovuto al maggior carico di lavoro a cui e` sottoposto il filesystem. Mutuando queste attivita` dal mondo dei database, ogni volta che il filesystem viene aggiornato, un record che descrive la transazione viene aggiunto ad un log seriale su disco, prima che i blocchi originali vengano aggiornati. Un thread processa queste transazioni, scrive i dati sul disco, e marca ogni transazione processata come completata. In caso di riavvio improvviso, questo thread semplicemente finisce di compiere quegli aggiornamenti dal log al filesystem che non sono segnati come completati. Transazioni incomplete nel journal vengono scartate, garantendo la consistenza interna del filesystem (ma non l'aggiornamento dei dati all'ultima modifica). La presenza del journaling consente di ridurre la complessita` del check di un filesystem di circa due ordini di grandezza. Il controllo completo di un un filesystem non e` quasi mai necessario, ed il ripristino dopo un reboot diventa questione di secondi Il journaling, per cui, consente di avere una situazione in cui o i dati sono consistenti sul filesystem, o si ha una situazione pienamente conclusa sul sistema di journal. Che poi i dati siano l'ultima versione, la precedente o quelli prima ancora non conta, saranno comunque consistenti. In conclusione, filesystem journaled assicura la coerenza dei dati, ma non la perdita dei file se il filesystem si danneggia: e` per questo che servono i backup.