mar
26

Sulla perdita dei dati dell’EXT4 e dei moti rivoluzionari

 

Un paio di settimane fa un utente aveva segnalato un grave problema relativo al nuovo file system ext4 recentemente incluso nel kernel Linux e dichiarato stabile.

La storia aveva dello straordinario perchè il nostro caro collega, in quanto utilizzatore di software libero, spiegava in un ticket di segnalazione del bug pubblicato su Launchpad come, dopo aver installato la versione alpha di kubuntu 9.04, abbia perso una grandissima quantità di dati in uno stop improvviso della macchina in questione.

In realtà i file erano presenti ma la loro dimensione era irrimediabilmente fissata sullo zero segno questo che non lascia ben sperare per il recupero degli stessi.

Da qui la polemica è divampata sulla rete in pochissimi secondi, le personalità più differenti si prodigavano nella denuncia del fatto che certamente ha sconvolto molti di coloro che utilizzano il software libero perchè ritenuto di qualità più alta.

Da che mondo è mondo se una cosa viene inclusa in una release del kernel significa che è matura, stabile e sicura.

Personalmente ho aspettato prima di fornire pareri ed eventualmente muovere critiche, volevo essere sicuro dei fatti e farmi una idea precisa dell’accaduto, analizzare per poi esporre realmente il problema è nella mia natura.

Passano i giorni, molto pochi in realtà, e vengo a sapere che il tizio che si occupa del file system ext4 ha rilasciato una patch per risolvere il problema, tale patch sarà disponibile nella release del kernel 2.6.30.

Decido allora di preparare una analisi semi approfondita della questione giusto per capire come e cosa è accaduto all’interno di quel disco rigido che ha dato il via alla piccola rivoluzione.

Genericamente quando un file viene alterato o modificato viene creato un primo file temporaneo (lo chiameremo A) che racchiude i nuovi dati e successivamente viene modificato l’indice dei file per far si che il vecchio file (lo chiameremo B) sia ora rintracciabile in un’altra locazione.

Questo processo da luogo a due condizioni; per prima cosa si ha un cambio dei metadati dei file all’interno del file system, viene creato un nuovo inode per il file temporaneo A che si andrà a scrivere e viene generata una nuova voce indice che punta al file A appena creato.

Una volta apportate le modifiche a questo nuovo file (A), e cambiato il suo nome, si reindirizza le informazioni di indice del vecchio file originario (B) a questa nuova posizione.

Ora si possono scrivere i dati e per fare ciò il sistema deve preparare una serie di blocchi sul disco sufficiente a stipare tutte le informazioni che si andranno a salvare.

In entrambe le tipologia di file system, parlo di ext3 e di ext4, vi è una protezione dei dati attraverso il sistema di journaling che effettua il commit, e quindi il cambiamento effettivo dei dati, solo quando le modifiche al file B sono terminate.

Un file di log si incarica di tenere traccia di tutte le attività svolte sul file, una volta che esse di possono considerare concluse vi è l’effettivo cambiamento delle informazioni.

Se in questa precisa fase si ha un calo della tensione del sistema è impossibile trovare all’avvio il nuovo file in quanto esso non è stato ancora creato e quindi, anche se ci dovessimo trovare nella condizione di aver già assegnato i parametri per l’indicizzazione del vecchio file alla nuova posizione, basterà un semplice riavvio del sistema per riportare tutto alla normalità pur avendo perso le nuove informazioni.

Purtroppo per noi però c’è una piccola ma sostanziale differenza tra i due file system (ext3 ed ext4), solo nel caso di un file system ext3, con opzione di mount in data=ordered (ovvero di ordinamento dei dati), i metadati vengono aggiornati dopo il commit delle nuove informazioni scritte nel file.

Questa operazione può richiedere fino a 5 secondi di tempo, in questo lasso di tempo le modifiche sono presenti solo nella cache del sistema ed è possibile che i blocchi di dati appena riservati alla nuova versione del file non presentino le modifiche apportate perchè facenti parte di un file appena eliminato o per altre cause.

In questa condizione dopo un crash del pc ci si ritroverebbe ad avere una versione vecchia o nuova delle informazioni a seconda che il down sia avvenuto prima o dopo la scrittura su disco.

Questo modo di operare permette di avere a disposizione sempre e comunque una versione dei dati che sia essa la più aggiornata o meno.

Ext4 dal canto suo invece opera in modo diverso in quanto ricorre alla assegnazione ritardata dei blocchi di memoria.

La scrittura dei dati quindi avviene in una fase successiva e secondaria alla chiusura delle modifiche sul file per permettere di ottimizzare il processo di scrittura reale su disco.

Questo metodo però lascia spazio ad una problematica ovvero quella di avere un file di dimensione 0 byte per non occupare blocchi di dati inutilmente fino al momento nel quale questo non venga scritto realmente su disco, momento che è ritardato nel tempo.

Se si verifica una interruzione dell’alimentazione in questa fase ci si ritrova nella condizione di avere un log di journaling dove l’operazione è stata già scritta come effettuata ma in realtà, proprio per la questione dell’allocazione ritardata dei blocchi su disco, essa non è realmente passata alla fase di commit.

Si crea una sorta di desincornizzazione tra cià che sono le modifiche scritte nel log del sistema di journaling e quelli che realmente sono i cambiamenti apportati.

La problematica sfocia quindi nella condizione di avere sia il vecchio che il nuovo file di dimensioni nulle.

Sicuramente un problema da sottolineare ma che trova riscontri simili in tutti quei file system che rispettano le direttive POSIX.

Lo stesso Ted T’so, curatore del progetto, ha dichiarato che la sicurezza dell’ext3 in queste occasioni non è una proprio caratteristica peculiare ma solo un effetto collaterale dovuto alla gestione dell’allocazione dei blocchi di dati del file system in questione.

Il problema si potrebbe manifestare soprattutto nel caso di applicazioni sviluppate seguendo come standard il comportamento anomalo del file system di precedente generazione.

La risoluzione dell’anomalia può essere affrontata in molti modi differenti, esattamente tre, ma la patch prontamente sviluppata da T’so prevede che l’azione di allocazione dei settori sia contemporanea a quella di scrittura delle informazioni (commit).

Non ci resta che attendere la release numero 2.6.30 per veder risolto il problema.

Personalmente ritengo che una situazione del genere sia difficile da reperire in situazione nelle quali il file system sia ospitato all’interno di dischi rigidi di un server visto che questo tipo di macchine sono (e devono essere) assistite da gruppi di continuità; è comunque vero che il problema andava scovato in anticipo e corretto prima di includere il supporto nel kernel Linux.

Ciao a tutti.

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

mar
18

Cosa sta accadendo nel mondo Linux…

 

È da quasi un mese che non scrivo sul blog. Un impegno improrogabile (leggasi «scuola») mi ha completamente sfinito e cosí quando accendo il computer ho voglia di fare una qualsiasi cosa che non sia impegnarmi a scrivere qualche frase di senso compiuto!

Ma ho deciso di ricominciare, come faccio da quasi un anno, ad appuntare informazioni piú o meno interessanti sul blog.

Come «riscaldamento», ho preso qua e là qualche news per vedere che cosa sta accadendo di interessante nel mondo Linux…

  • Riguardo il toolkit GTK+, qualcosa si sta muovendo: è stata rilasciata la nuova versione 2.16.0, che porta con sé qualche piccola novità come la possibilità di personalizzare maggiormente la finestra «Selettore file».
  • Continua a pieno regime lo sviluppo di GNOME, di cui è già possibile assaggiare la versione 3, seppur in uno stato embrionale (istruzioni per la compilazione su Pollycoke).
  • David Vignoni, per gli amici «Icon king», ha scritto sul suo blog un interessante articolo riguardo l’unica parte di KDE 4 che sembra essere uscita dalla preistoria: il login manager, KDM.
  • Grande notizia da Iperbole, il sito Web della città di Bologna (la mia!): sembra infatti che la struttura informatica del Comune stia migrando lentamente verso soluzioni open-source come, ad esempio, OpenOffice al posto del vetusto Microsoft Office ‘97 (che, non ci crederete, è l’attuale programma di videoscrittura utilizzato nei computer del Comune).
  • Chi usa il nuovo filesystem Ext4 potrebbe perdere dei file, in particolare quelli di piccole dimensioni. La colpa però non è di Ext4, ma dei programmi che utilizzano degli «stratagemmi» per funzionare correttamente con il predecessore Ext3.

Basta! Se volete sapere che succede di bello nel mondo Linux ci sono fonti piú attendibili ed aggiornate di me: una su tutte, Slashdot.com. A presto ;-)

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

mar
13

Ext4 a rischio di perdita dati?

 

La modalità “Delayed Allocation” del nuovo filesystem Ext4 potrebbe causare perdite di dati soprattutto a danno di files di configurazione e addirittura di files di database.

E’ quanto viene segnalato in un bugreport per la prossima release di Ubuntu (la 9.04 Jaunty Jackalope). Secondo il report, se avviene un crash ad esempio durante il caricamento dei files di configurazione di Kde4, al successivo riavvio si potrebbe avere la perdita di grosse parti di files di configurazione; l’utente autore della segnalazione segnala anche perdite di dati per i files di Database.

Secondo Theodore Ts’o, principale sviluppatore di Ext4, il problema è dovuto appunto alla modalità “Delayed Allocation”, e il problema è evidente soprattutto quando vengono gestite grandi quantità di files di piccole dimensioni, come accade ad esempio per l’ambente Kde4 o Gnome in fase di caricamento dei files di configurazione.

Lo sviluppatore ha dichiarato che il problema affligge anche altri filesystem come XFS, e Brtfs e ha inoltre assicurato che le patch al problema verranno inserite nel kernel 2.6.30.

Via | TuxJournal

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

mar
11

EXT4, uno sguardo al futuro

 

Con la release numero 2.6.28 dello scorso Dicembre sono state introdotte molte novità la più importante è sicuramente in pieno e stabile supporto al file system di nuova generazione ext4.

I vantaggi rispetto al tipo ext3 sono molteplici e vanno dalla scalabilità alla affidabilità, in realtà non si può parlare di vera e propria rivoluzione della tecnologia che vi è alle spalle del progetto visto che esso è il frutto di un’opera di revisione e miglioramento del già potente ext3.

Prima di osservare da vicino le caratteristiche del nuovo ext4 è bene fare un piccolo riassunto storico di quelle che sono state le tappe che ci hanno portato a questa implementazione:

  1. nell’Aprile 1992 nasce il file system ext ad opera di Remy Card, implementazione del file system virtuale (VFS) e supporto fino ad una dimensione massima di 2 Gb erano le caratteristiche principali.
  2. nel Gennaio 1993 vede la luce il file system ext2 questa volta Remy Card ha integrato dei miglioramenti attraverso l’implementazione di soluzioni riscontrabili in altri progetti come il FFS; massima estensione di 2TB fino ad un massimo di 32 TB dopo il rilascio del kernel 2.6
  3. Novembre 2001, ext3 debutta e, anche se presenta prestazioni leggermente inferiori ad altri in alcuni campi di applicazione, introduce notevoli innovazioni come il sistema di journaling che ne migliora l’affidabilità. Il creatore è Stephen Tweedie.
  4. Dicembre 2008, ext4 entra di diritto come stabile nel kernel Linux dopo essere stato testato per lungo tempo dal gruppo di sviluppo alla guida di Theodore Tso già manutentore di ext3.

Funzionalità EXT4

La prima importante funzionalità che possiamo trovare i ext4 è l’estrema compatibilità con il file system che lo precede.

Il principale obbiettivo di una migrazione ad un nuovo e più performante file system dovrebbe essere quello di poter essere il più indolore e semplice possibile, questa volta sembra che lo scopo sia stato centrato in quanto è possibile montare vecchie partizioni ext3 come fossero ext4 oltre a questo è stata implementata una tecnologia in grado di effettuare una migrazione graduale.

Grazie alla capacità di archiviare i nuovi file che si andranno a scrivere su di una partizione ext3 montata in ext4 come se fossero delle informazioni che vanno ad archiviarsi direttamente su di un file system ext4 nativo si può avere una migrazione tipo on-line.

In questo modo è possibile migrare in modo semplice un ext3 visto che la lenta sostituzione dei file del volume andrà automaticamente a convertire il volume nel nuovo formato.

Questo particolare tipo di migrazione, anche se personalmente non ritenuta una soluzione soddisfacente, sicuramente farà la felicità di molti utenti che non hanno le capacità tecniche o la pazienza di dare atto ad una conversione tradizionale.

Di seguito una tabella di compatibilità del nuovo ext4:

figure1.gif

Il secondo miglioramento che è possibile far rientrare nel campo delle nuove funzionalità riguarda il range e la risoluzione del timestamp.

Incredibilmente il timestamp di tutti i file system ext prima dell’avvento della quarta versione era basato sul secondo.

Con l’incremento di prestazione dell’hardware degli ultimi periodi e l’utilizzo del sistema operativo GNU/Linux su particolari settori ad alte prestazioni di calcolo l’unità di misura limite del secondo è diventata rapidamente obsoleta per essere utilizzata come limite di timestamp.

La soluzione è stata l’implementazione del nanosecondo come misura limite estendendo nel contempo di due bit il range del tempo per permettere l’estensione della durata della vita del file system di altri 500 anni.

Scalabilità

Uno dei principali limiti dell’ext3 era reperibile nella sua impossibilità di gestire grandi array di dischi dai volumi enormi.

Con la rivoluzione della rete e la creazione degli ormai famosi e tanto sbandierati servizi web 2.0 la capacità di archiviazione è uno di quei parametri che può fare la fortuna o la disgrazia di un moderno file system.

A tal proposito l’ext4 è in grado dar supporto a file system con una dimensione massima di 1 Exabyte con una dimensione massima dei file fino a 16 TB supponendo blocchi di dati da 4 KB.

Oltre a tutta questa profusione di numeri è stata definitivamente archiviata la limitazione per la profondità dello sotto-cartelle che ora è virtualmente illimitata.

Altra innovazione è rintracciabile nel meccanismo di allocazione, ext4 migliora sensibilmente questo aspetto che era un vero tallone d’Achille per il vecchio ext3.

Il file system di precedente generazione si comportava in modo egregio con i file di piccole dimensioni ma era tremendamente lento per quel che riguarda i file di notevoli dimensioni, in una situazione di contiguità delle informazioni il file system ext4 non fornisce le informazioni per ogni singolo blocco ma piuttosto restituisce la posizione dell’intero elenco di blocchi.

Questo metodo permette di trattare in modo efficiente sia i piccoli file, come nel precedente FS, sia i file di grandi dimensioni visto che le informazioni non riguardano il singolo blocco di dati ma, se consequenziali, il suo insieme.

Prestazioni

Uno dei primi parametri di valutazione per un nuovo FS è la velocità con il quale esso è in grado di lavorare.

Ci sono chiaramente diverse tecnologie che permettono di aumentare le prestazioni di un nuovo progetto ma molto spesso si predilige agire con strumenti conosciuti.

Ext4 ha subito dei notevoli miglioramenti nel comparto di preallocazione dei file ed adotta tecniche tali da migliorare la consequenzialità dei dati che andranno scritti su disco, questo evita, in fase di lettura e di modifica del file, di far rincorrere i settori scritti dalla testina del disco rigido per aumentarne così la velocità di trasferimento vista la ridotta necessita di spostamenti che occorrono per portare al termine le operazioni.

Un secondo metodo che ci permette di ottenere questi effetti è individuabile nella tecnica di ritardo di allocazione del blocco delle informazioni.

Se si ritarda la scrittura dei file fino alla chiamata flush, invece di agire alla chiamata write, si ha come conseguenza un compattamento delle informazioni in settori contigui risparmiando nel contempo cicli di scrittura visto che in questo modo si diminuisce notevolmente la necessità di scrivere i file temporanei, caratterizzati da una vita brevissima, sul disco stesso.

Certamente ci sono anche degli svantaggi visto che utilizzando questa tempistica i file residenti in memoria, e non ancora scritti su disco, risulteranno per sempre persi in caso di interruzione dell’alimentazione.

Affidabilità

Sicuramente un rinnovo del FS non poteva non passare per una migliorata affidabilità dello stesso.

Il sistema di journaling ora è nettamente più evoluto e può operare in differenti modalità:

  • Writeback mode: journaled dei soli metadati
  • Ordered mode: una modalità nella quale i metadati sono journaled ma anche i dati godono di una forma di protezione
  • Journal mode: sia i metadati che i dati sono journaled

chiaramente solo la terza modalità offre piene garanzia ma si rivela anche come il metodo di controllo più lento.

Sul fronte dell’affidabilità gioca un ruolo particolare anche la deframmentazione del disco che nel caso di ext4 è definibile come una frammentazione di tipo on-line.

Molto semplicemente la tecnologia si preoccupa di copiare i file deframmentati e sparsi sul disco in una nuova locazione più grande in grado di accogliere lo stesso completamente senza spezzare i dati in due o più parti.

La stessa tecnologia permette inoltre di accorciare in modo drastico i tempi necessari al controllo del disco tramite fsck visto che i blocchi inutilizzati saranno marcati come tali e quindi completamente ignorati durante il controllo di routine.

Conclusioni

Questo nuovo FS ha tutte le carte in regola per divenire un buon prodotto e, secondo quanto mostrato durante i primi test, sembra essere molto veloce tanto da distaccare in modo netto gli altri concorrenti.

Ciao a tutti.

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

mar
03

Ubuntu 9.04 sarà più veloce di Ubuntu 8.10

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

feb
12

Un altro benchmark su ext4!

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

gen
26

Fedora 11: a Maggio con Ext4

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

gen
25

Linux come Windows, la deframmentazione del filesystem

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

gen
15

Facciamoci tentare da Ext4

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

gen
14

Ext4 sempre più realtà: arriva “definitivamente” anche su Ubuntu

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

gen
09

Ext3 vs Ext4: il benchmark!

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

gen
08

Il nuovo kernel Linux 2.6.28

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

gen
06

Ext4 su Ubuntu 8.10

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

dic
31

Remembering 2008…..

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

dic
28

Ext4, impariamo a conoscerlo!

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

top