Il vincitore del concorso tenutosi negli ultimi post ha scelto come argomento una questione un po' spinosa. Perché ogni tot avvii di GNU/Linux avviene il controllo del filesystem, quando il filesystem è di tipo EXT? Fortuna che tra i feed che seguo c'è la serie
developerWorks di IBM :-)
Premetto subito che, se il filesystem scelto è ext3 (ossia la versione con journal) tale controllo si potrebbe disabilitare perché c'è già il journal. Però, prima, vorrei ricordare che il filesystem e la correttezza dei dati in esso contenuti è cosa abbastanza delicata. Talmente delicata che se in passato, come me, avete scelto di usare una certa distribuzione francese perché la trovavi nelle riviste con tutti i sui CD e programmi (sì, compreso gcc e pacchetti -devel) e perché faceva uso di un altro famoso e figo filesystem con journal prima che fosse largamente adottato e provato, allora, come me, potreste aver provato l'onta della perdita di parecchi dati - oddio, talvolta aiuta a ripartire da zero e a eliminare vecchie email di vecchi amori che non avreste mai il coraggio di eliminare motu propriu.
Il file system ext3 è stato progettato dal Dr. Stephen Tweedie, basandosi sulla struttura del filesystem ext2. L'unica, minuscola differenza tra i due è che ext3
supporta il journal.
Tale minuscola differenza in realtà comporta un comportamento estremamente diverso. Sebbene infatti la rappresentazione più semplice che si possa fare pensando a un filesytem è quelle di un luogo in cui
memorizzare i dati, bisogna tenere presente che il file system deve anche consentire il
recupero e la
manipolazione di tali dati. Per tali finalità ogni filesystem (nel senso di modello astratto) prevede la definizione di una
struttura dati interna definiti
metadata. In definitiva quindi i metadata che un certo filesystem definisce e gestisce (e il modo in cui lo fa) caratterizza il filesystem stesso.
I metadata non sono visibili all'utente, né d'altronde potrebbero servirgli a qualche scopo. Sebbene spesso si usi lo stesso nome, non stiamo qui parlando di cose tipo il tag "artista" di un file MP3. L'unica cosa che deve interessare l'utente a proposito dei metadata è che questi si trovino in uno stato
coerente,
non corrotto. In caso contrario è impossibile accedere ai file e li si è persi in modo più o meno definitivo (vedi parte finale del secondo paragrafo).
In passato il compito di mantenere i metadati in uno stato coerente era affidato ai programmi
unmount e
fsck. Il primo veniva invocato durante l'arresto del sistema per tutti i filesytem montati e si occupa di riversare su disco tutte le operazioni ancora pendenti (mica penserete che tutto avviene in modo sincrono, vero?), comprese quindi le operazioni relative ai metadata. Il secondo veniva invocato durante l'avvio per controllare due cose: se il filesystem fosse in uno stato usabile (ossia se è stato smontato in modo pulito) e se i metadata fossero coerenti; entrambi i controlli erano (e sono ancora) effettuati prima di montare il filesystem, il secondo eseguito se il filesystem era in uno stato non usabile, cioè se non era stato usato
umount.
Ora, come da lamentele del povero buon ORGA, il controllo dei metadata prende parecchio tempo, specie con filesystem grandi. Per risolvere il problema, i progettisti di filesystem hanno ben pensato di aggiungere una nuovo struttura di dati, il cosiddetto
journal. Nel journal, prima che si applichino i cambiamenti ai metadata,
vengono scritte le operazioni che descrivono tali cambiamenti. Basta. Punto. Finito qui. Aspettavate chissà quale grande pensata? Hanno solo aggiunto un "terzo livello", così da avere i data (la vostra roba), i metadata (dati relativi alla vostra roba) e meta-metadata (il journal, dati relativi ai dati relativi alla vostra roba).
Il trucco funziona perché, in caso di filesystem non coerente,
fsck non deve leggere tutto il filesystem controllando tutti i metadata, ma si può limitare a leggere il journal e applicare le modifiche qui elencate (che sono operazioni non applicate ai metadata per renderli coerenti).
Perché quindi ogni TOT avvii ci si presenta quella fastidiosa scansione? Forse per la legge di Muphy, perché va bene che il journal è cosa buona, ma la paranoia è anche meglio. Per cui un bel controllo vecchia maniera di tutti i metadata una volta ogni tanto non guasta.
In effetti a tale proposito ci sono due scuole di pensiero. La prima è "
c'è il journal, che ce ne frega di controllare i metadata". La seconda, io credo più corretta, dice "
c'è il journal... ma allora in caso di problemi relativi all'unità, ai cavi, alla memoria o a bug del kernel potrei non accorgermi[1] che il mio filesystem è diventato corrotto". La conclusione della seconda scuola di pensiero è ciò che avete sotto gli occhi: meglio perdere tempo ogni tanto per un controllo approfondito che perdere dati.
Aggiornamento: non l'ho scritto esplicitamente nel precedente paragrafo, ma, se dopo un arresto non pulito ripristino solo il journal e non controllo tutti i metadata, non potrò sapere se ci sono metadata corrotti, derivanti non dalla non sincronizzazione del journal, ma dalle cause "esterne" prima elencate. È più chiaro, adesso?
Se siete coraggiosi, comunque, potete disabilitare tale controllo con il seguente comando (consultate la pagina di manuale di tune2fs per il significato):
sudo tune2fs -c 0 -i 0 /dev/PARTIZIONE
Se siete un po' meno coraggiosi, avete comprato hardware di prima qualità e il vi sembra che il controllo capiti troppo spesso, potete più rilassatamente aumentare i tempi da attendere tra un controllo e l'altro. Per prima controllate con dumpe2fs le attuali impostazioni:
sudo dumpe2fs -h /dev/PARTIZIONE
Nell'output del comando si sono la riga "Maximum mount count: xx" e "Check interval: yyy" : indicano che dopo xx mount o yyy giorni|settimane|mesi verrà eseguito il controllo completo. I valori predefiniti solo xx=20 mount e yyy=10 giorni. Per incrementare il numero di mount, usare:
sudo tune2fs -c 60 /dev/PARTIZIONE
Letture interessanti
[1] o accorgermi troppo tardi: stando al manuale di fsck se il kernel rileva un errore nel filesystem forza l'esecuzione di fsck al successivo riavvio, quando ormai potrebbe essere troppo tardi.
