Buon fine settimana a tutti! Ti invitiamo a una lezione demo gratuita , condotta da Andrey Burano — specialista di sistemi UNIX presso Mail.Ru Group. Pubblicheremo anche un articolo di Jonathan Corbet — Executive Editor di LWN.net.
I file system journaling promettono di liberare gli amministratori di sistema dai problemi di danneggiamento del disco durante i crash di sistema. Anche senza eseguire un controllo dell'integrità del file system. Tuttavia, in realtà, tutto è un po' più complicato. E come dimostra una recente discussione, potrebbe addirittura essere più confuso di quanto molti di noi pensino, poiché la garanzia dell'integrità dei file system journaling influisce sulle prestazioni.
Un file system come ext3 utilizza un'area separata sul disco chiamata registro. Quando vengono apportate modifiche ai metadati del file system, queste modifiche vengono prima registrate nel registro senza modificare il resto del file system. Dopo che tutte le modifiche sono state scritte nel registro, viene aggiunto un "commit block" che indica il completamento della transazione. Solo dopo la registrazione del commit block, la transazione viene fissata e i metadati modificati sono scritti sul disco. Se il sistema si guasta in un certo momento, le informazioni nel registro possono essere utilizzate per completare l'operazione in modo sicuro ed evitare danni al file system a causa dell'aggiornamento solo di una parte dei metadati.
Tuttavia, c'è un problema: il codice del file system, prima di eseguire il commit di un blocco, deve essere assolutamente certo che tutte le informazioni sulla transazione siano già state scritte nel journal. Registrare semplicemente le operazioni nell'ordine corretto non è sufficiente: i dischi moderni supportano grandi cache interne e riordinano le operazioni per migliorare le prestazioni. Pertanto, prima di eseguire il commit del blocco, è necessario indicare esplicitamente il trasferimento di tutti i dati del journal su disco. Se il blocco di commit viene registrato prima, il journal potrebbe danneggiarsi. Per risolvere questo problema, sono utilizzati i barrier. Essenzialmente, un barrier impedisce la scrittura di qualsiasi blocco dopo di esso, fino a quando tutti i blocchi scritti prima del barrier non siano stati trasferiti su disco. Utilizzando i barrier, i file system garantiscono la coerenza delle strutture dei file.
Ma c'è un altro problema: i file system ext3 ed ext4 di default non utilizzano i barrier. L'opzione esiste, ma se l'amministratore non li attiva esplicitamente, questi file system funzionano senza barrier, anche se in alcune distribuzioni (come SUSE) i valori di default sono diversi. Eric Sandeen ha recentemente deciso che questa situazione deve essere cambiata e , che modifica le impostazioni di default per ext3 ed ext4. E così è iniziata una vivace discussione.
Andrew Morton ha risposto molto dettagliatamente , spiegando perché il valore di default sia proprio questo:
L'ultima volta che abbiamo provato a cambiarlo, le prestazioni sono diminuite del 30% sotto molti carichi, quindi ho scartato con orrore tutte quelle patch. Penso che non possiamo permetterci questo, rallentando così seriamente tutti i sistemi...
Non ci sono soluzioni ideali, e sono incline a non svegliare questo cane addormentato e a lasciare i parametri di default a discrezione degli sviluppatori delle distribuzioni.
Pertanto, per impostazione predefinita, i barrier sono disattivati, poiché influenzano seriamente le prestazioni. Inoltre, i file system vengono utilizzati con successo senza barrier. I messaggi di danneggiamento del file system ext3 sono piuttosto rari.
Ma non si tratta solo di fortuna. Ted Ts’o è che il journal ext3 / ext4 è solitamente posizionato in modo continuo. In primo luogo, il driver del file system cerca di crearlo in modo continuo. In secondo luogo, il journal è solitamente creato insieme al file system, quando è facile trovare uno spazio continuo. La continuità e l’ordinamento sono utili non solo per le prestazioni, ma anche per prevenire il riordino. Di solito, il commit block viene posizionato subito dopo i dati nel journal, quindi il disco non ha motivo di riordinare. Il commit block viene naturalmente scritto su disco subito dopo le altre voci del journal.
Tuttavia, nessuno sostiene che sia così per sempre. I dischi possono comportarsi in modo diverso. Inoltre, il log funge da buffer circolare. Quindi, quando una transazione viene registrata alla fine del log, il blocco di commit può trovarsi in un blocco precedente, davanti ad altre registrazioni del log. Quindi, esiste sempre la possibilità di danneggiamento. In effetti, Chris Mason ha per questo . Non c'è dubbio che lavorare senza barriere sia meno sicuro che con esse.
Se sei disposto ad accettare un colpo alle prestazioni, puoi abilitare le barriere. Questo, ovviamente, se il tuo file system non è basato su LVM (come in alcune distribuzioni per impostazione predefinita). Si scopre che il device mapper non supporta le barriere. In altri casi, sarebbe utile ridurre la diminuzione delle prestazioni. E sembra che sia possibile farlo.
L'attuale implementazione di ext3 (quando le barriere sono attivate) esegue la seguente sequenza di operazioni per ogni transazione:
I dati vengono scritti nel log
Viene eseguita la barriera
Viene registrato il blocco di commit
Viene eseguita la barriera successiva
Successivamente, i metadati vengono scaricati sul disco
In ext4, the first barrier (step 2) can be omitted, as the ext4 file system supports checksums in the journal.
If the journal data and commit block are reordered, and the operation is interrupted due to a failure, the journal checksum will not match the one stored in the commit block, and the transaction will be rejected.
Chris Mason , it would be "generally safe" to remove this barrier in ext3 as well, with the possible exception when the journal reaches the end and starts writing from the beginning.
Another idea to speed up operations is to defer barrier operations when possible. If there's no urgent need to flush data to disk immediately, multiple transactions can be created in the journal and flushed to disk with a single barrier.
There is also some potential for improvement through careful ordering of operations, so that barriers (which are usually implemented as requests to "flush all pending operations to disk") do not force the writing of blocks that do not require ordering.
It seems the time has come to consider how to make the cost of barriers acceptable. Ted Tso seems to be thinking about this. :
Penso che dovremmo incorporare i barrieri in ext3/ext4 e poi lavorare per ridurre il sovraccarico in ext4/jbd2. È probabile che la grande maggioranza dei sistemi non operi in condizioni simili a quelle usate da Chris per dimostrare il problema e la sicurezza del filesystem dovrebbe essere una priorità.
Il buon senso mi dice che questo cane non dorme più e probabilmente abbaierà per un po'. Questo potrebbe preoccupare alcuni vicini, ma è meglio piuttosto che permettergli di mordere.
Sei interessato a svilupparti in questo ambito? Iscriviti a una lezione Demo gratuita e partecipa alla trasmissione , condotta da Pavel Vikiryuk — operatore di rete MVNO, ingegnere DevOps.
Fonte: habr.com
