A tutti un ottimo fine settimana! Vi invitiamo a una lezione demo gratuita , condotta da Andrei Buranov — specialista in sistemi UNIX della 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 in caso di crash del sistema. Anche senza l'esecuzione di un controllo di integrità del file system. Anche se in realtà, naturalmente, le cose sono un po' più complesse. E come dimostra una recente discussione, potrebbe essere addirittura più complicato di quanto molti di noi pensino, poiché il mantenimento dell'integrità dei file system journaling influisce sulle prestazioni.
Un file system come ext3 utilizza un'area separata sul disco, chiamata journal. Quando vengono apportate modifiche ai metadati del file system, queste modifiche vengono prima registrate nel journal senza modificare il resto del file system. Dopo aver registrato tutte le modifiche nel journal, viene aggiunto un 'commit block', che indica il completamento della transazione. Solo dopo la registrazione del commit block, la transazione viene finalizzata e i metadati modificati vengono scritti sul disco. Se il sistema si arresta in un certo momento, le informazioni nel journal possono essere utilizzate per completare l'operazione in sicurezza ed evitare il danneggiamento del file system, poiché solo una parte dei metadati era stata aggiornata.
Tuttavia, c'è un problema: il codice del file system deve essere assolutamente certo che tutte le informazioni sulla transazione siano già state inserite nel journal prima di scrivere il commit block. Scrivere 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 del commit block, è necessario indicare esplicitamente il trasferimento di tutti i dati del journal sul disco. Se il commit block viene registrato prima, il journal potrebbe essere danneggiato. Per risolvere questo problema vengono utilizzate le barriere. Fondamentalmente, una barriera impedisce la registrazione di qualsiasi blocco dopo la barriera, fino a quando tutti i blocchi registrati prima della barriera non vengono trasferiti sul disco. Utilizzando le barriere, i file system garantiscono la coerenza delle strutture dei file.
Ma c'è un altro problema: i file system ext3 e ext4 di default non utilizzano i barriere. C'è un'opzione, ma se l'amministratore non l'ha attivata esplicitamente, questi file system funzionano senza barriere, anche se in alcune distribuzioni (ad esempio, SUSE) i valori predefiniti sono diversi. Eric Sandeen di recente ha deciso che questa situazione deve essere cambiata e , che modifica le impostazioni predefinite per ext3 e ext4. E così è iniziata una vivace discussione.
Andrew Morton ha spiegato in dettaglio , perché il valore predefinito è proprio così:
L'ultima volta che abbiamo cercato di modificarlo, le prestazioni su molti carichi di lavoro sono diminuite del 30%, quindi ho gettato via tutte queste patch con orrore. Penso che non possiamo permetterci di rallentare tutte le macchine in questo modo…
Non ci sono soluzioni perfette, e sono propenso a non risvegliare questo cane addormentato e lasciare i parametri predefiniti a discrezione degli sviluppatori delle distribuzioni.
Pertanto, di default i barriere sono disattivati, poiché influenzano seriamente le prestazioni. Inoltre, i file system sono utilizzati con successo anche senza barriere. I report di danneggiamento del file system ext3 sono pochi e rari.
Ma non si tratta solo di fortuna. Ted Ts'o è il fatto che il journal ext3 / ext4 è normalmente posizionato in modo continuo. In primo luogo, il driver del file system cerca di crearlo in modo continuo. In secondo luogo, il journal viene generalmente creato insieme al file system, quando è facile trovare uno spazio contiguo. La continuità e l'ordine sono utili non solo per le prestazioni, ma anche per prevenire il riordino. Di solito, il blocco di commit viene posizionato subito dopo i restanti dati nel journal, quindi l'unità disco non ha motivi per riordinare. Il blocco di commit viene naturalmente scritto sul disco subito dopo le altre registrazioni del journal.
Tuttavia, nessuno sostiene che sia sempre così. I dischi possono comportarsi diversamente. Inoltre, il journal è un buffer circolare. Quindi, quando una transazione viene scritta alla fine del journal, il blocco di commit può trovarsi in un blocco precedente, prima di altre registrazioni nel journal. Quindi, la probabilità di danneggiamento è sempre presente. In realtà, Chris Mason ha un'osservazione in merito. . Non c'è dubbio che lavorare senza barriere sia meno sicuro che con esse.
Se sei pronto a subire un colpo alle prestazioni, puoi attivare le barriere. Questo, ovviamente, se il tuo file system non è basato su LVM (come in alcune distribuzioni di default). A quanto pare, il device mapper non supporta le barriere. In altri casi, sarebbe opportuno ridurre la perdita di prestazioni. E, a quanto sembra, si può fare.
L'attuale implementazione di ext3 (quando le barriere sono attivate) esegue la seguente sequenza di operazioni per ogni transazione:
I dati vengono scritti nel journal
Viene eseguita la barriera
Viene scritto il commit block
Viene eseguita la successiva barriera
Successivamente, i metadati vengono scritti su disco
In ext4, la prima barriera (passo 2) può essere omessa, poiché il file system ext4 supporta le checksum nel journal.
Se i dati del journal e il commit block sono riorganizzati, e l'operazione è interrotta a causa di un guasto, la checksum del journal non corrisponderà a quella memorizzata nel commit block, e la transazione verrà annullata.
Chris Mason , che sarebbe "in generale sicuro" rimuovere questa barriera anche in ext3, a meno che il journal non arrivi alla fine e ricominci a scrivere dall'inizio.
Un'altra idea per migliorare le prestazioni è quella di posticipare le operazioni con le barriere, quando possibile. Se non c'è urgenza di scrivere subito i dati su disco, si possono creare diverse transazioni nel journal e scrivere su disco con una sola barriera.
C'è anche un certo potenziale per miglioramenti attraverso un'attenta organizzazione delle operazioni, in modo che le barriere (che di solito sono implementate come richieste di "scrivi tutte le operazioni in sospeso su disco") non forzino la scrittura di blocchi non ordinati.
Sembra sia arrivato il momento di pensare a come rendere il costo delle barriere accettabile. Ted Ts'o, sembra :
Penso che dovremmo attivare le barriere in ext3/4 e poi lavorare per ridurre il sovraccarico in ext4 / jbd2. È probabile che la stragrande maggioranza dei sistemi non operi in condizioni simili a quelle che Chris ha usato per dimostrare il problema e la sicurezza del file system per default deve essere una priorità.
Il buon senso mi dice che questo cane non sta più dormendo e probabilmente abbaierà per un po'. Questo potrebbe preoccupare alcuni vicini, ma è meglio che permetterle di mordere.
È interessante svilupparsi in questa direzione? Iscriviti a una Demo-lezione gratuita e partecipa alla trasmissione , che sarà condotta da Pavel Vikiрюk — operatore di rete MVNO, ingegnere DevOps.
Fonte: habr.com
