Configurazione ext4 "sicura" per i sistemi che funzionano incustoditi

Ho un sistema che esegue Linux che deve funzionare incustodito per lunghi periodi di tempo. Il sistema utilizza una scheda CF industriale per la memorizzazione. La maggior parte delle volte non ci sono scritture da lampeggiare, anche se ogni tanto alcuni dati / impostazioni di configurazione possono essere modificati. Il sistema deve essere resistente alle interruzioni di corrente.

Vorrei usare ext4 per questo. Qual è il modo migliore per configurare ext4 per questo tipo di installazione? Tenendo presente che:

• Le prestazioni non sono affatto un problema (in particolare le prestazioni di scrittura)
• In caso di interruzione dell'alimentazione, il sistema dovrebbe sempre avviarsi in uno stato pulito, anche se ciò significa che i dati scritti negli ultimi secondi vanno persi
• Se è possibile evitare fsck, tanto meglio.

(Sono a conoscenza di questa domanda correlata: prevenire la corruzione dei dati sull'unità ext4 / Linux in caso di interruzione dell'alimentazione )

Ho lavorato nella costruzione di un sistema per l'automazione delle barche, e c'era un prerequisito: in ogni momento la potenza poteva scendere e tutto doveva riprendersi correttamente.

La mia soluzione era quella di creare un sistema initramfs basato su Gentoo, con solo una cartella rw per applicazioni e configurazioni (questo è l'approccio utilizzato da tutti i fornitori di router / firewall). Questa soluzione aggiunge un ulteriore livello di complessità quando si tratta di aggiornamenti di sistema, ma assicura che il sistema si avvierà SEMPRE.

Per quanto riguarda la tua domanda specifica, dovresti tenere abilitato il journal EXT4 per avere fsck più veloce (di alcuni secondi), usare l' opzione data = journal mount, abbassare l' opzione di commit o usare l' opzione di sincronizzazione per mantenere i buffer sempre vuoti.

Rif: http://www.kernel.org/doc/Documentation/filesystems/ext4.txt

Premetto questo dicendo che, per quanto mi riguarda, EXT (in tutte le sue incarnazioni) è un filesystem piuttosto orribile - ho visto casi più " interessanti " di corruzione del filesystem nel numero relativamente piccolo di Linux / EXT {2,3,4} sistemi che ho amministrato di quanti ne abbia nel numero relativamente elevato di filesystem Not-EXT che ho avuto occasione di usare.
Se possibile, prova a scegliere un filesystem più robusto. Ti ringrazierai quando succederà l'inevitabile.

Detto questo e tutti i miei pregiudizi personali all'aperto e messi da parte, EXT4 ha tre caratteristiche che posso pensare che potrebbero aiutarti:

• Journaling
  EXT4 può essere un filesystem journaled, se lo si desidera. Abilitare la funzione journaling (e impostare in modo specifico la modalità journaling dati su journaltramite tune2fso come opzione di montaggio).
  Ciò comporta un impatto sulle prestazioni in quanto tutti i dati devono essere scritti nel journal EXT prima che vengano "impegnati" nel filesystem (ogni scrittura in pratica avviene due volte) ma garantisce che tu possa sempre recuperare fino a quando un replay del journal ti porterà senza alcun i problemi.

• SYNChronous Mounts
  Quando la sicurezza è fondamentale montare un filesystem con l' syncopzione è sempre una buona idea. Questo forza immediatamente tutte le scritture su disco - anche in questo caso si tratta di un successo prestazionale, ma una buona idea se ti aspetti interruzioni di corrente o estranei casuali che tirano fuori la scheda CF.

• Limita il più possibile i filesystem scrivibili Questo non è specifico di EXT, ma la filosofia Linux fin troppo comune di "creare una grande partizione di root e scaricare tutto in essa" è, francamente, stupida . Creare una struttura di file system corretto ( /, /var, /usr, /home, ecc ...), e montare come molti dei filesystem di sola lettura possibile.
  Questo era un consiglio comune per i sistemi unix per motivi di sicurezza, ma nel tuo caso ha un ulteriore vantaggio: non puoi corrompere un filesystem se non puoi scriverci.

EXT4 non sembra la scelta migliore per il tuo sistema; Suggerirei di guardare un filesystem strutturato in log. Funzionano trattando i dati come un flusso costante di aggiornamenti in scrittura rispetto a un flusso virtuale, con un puntatore che punta all'ultima "testa". Gli aggiornamenti avvengono scrivendo dati e metadati nella memoria, quindi aggiornando il puntatore. In caso di arresto anomalo dopo la scrittura ma prima dell'aggiornamento del puntatore si perdono gli ultimi dati ma il filesystem è coerente.

Due filesystem candidati sono LogFS e NILFS . Entrambi sono disponibili nel kernel principale di Linux.

Sono incuriosito dal dispositivo che costruisci. Stai cercando l'affidabilità di un dispositivo incorporato mentre usi un filesystem che non è davvero adatto.

Ext4 (e famiglia) è un file system per scopi generici con (immagino) molti miliardi di ore di utilizzo su hardware e casi d'uso diversi. Tuttavia, ciò che stai chiedendo non si adatta davvero a ext4. I suggerimenti di voretaq7 e Giovanni aiuteranno ad ottenere il meglio dall'uso di ext4 se necessario, ma la vera risposta è usare qualcosa di più adatto alle proprie esigenze. Steve ti ha dato un paio di opzioni. Se continui a trarre energia da un FS ext4 alla fine avrai un casino.

Se questo è un sistema unico che stai costruendo, dovresti scegliere di usare qualcosa di più adatto o accettare che ci saranno problemi ad un certo punto. Potrebbe trattarsi solo di un'interruzione di corrente su 100 o 1 su 1000. Potrebbe essere abbastanza buono per correre il rischio e il dispositivo potrebbe funzionare a lungo (anni) senza alcun intervento manuale.

Se si tratta di un prodotto che si intende implementare ampiamente / portare sul mercato, si ha la scelta di utilizzare qualcosa di più adatto. Oppure prendi la decisione aziendale di supportare una percentuale dei dispositivi che funzioneranno ogni anno e dovranno essere sostituiti o interventi manuali per recuperarli.