Quale filesystem offre la migliore protezione per proteggere i dati dalla corruzione a causa della perdita di potenza?

Sto eseguendo un sistema integrato piccolo uClibce busyboxbasato su un dispositivo x86. Sto usando un initramfs ma sto anche montando una ext3directory personalizzata su un dispositivo flash compatto in modalità IDE che sto usando per memorizzare dati persistenti di registrazione delle misure creati da un'applicazione c ++ scritta personalizzata. Ho scelto il ext3file system perché è raccomandato per la sicurezza contro la perdita di potenza quando si usano unità CF in modalità IDE in un paio di libri che ho letto ( Creazione di sistemi Linux incorporati di Karim Yaghmour e Embedded Linux Primer di Christopher Hallinan). Questo è particolarmente importante e i dati sono fondamentali.

Tuttavia, a causa di alcuni dei commenti nella mia precedente domanda Confusione su come ripristinare i file ext3 corrotti se si verifica un'interruzione dell'alimentazione durante la scrittura di un file , sembrerebbe che in realtà questo file system non offra la garanzia di sicurezza contro la corruzione dei dati dovuta all'alimentazione perdita. Quindi vorrei sapere se

1. In ext3realtà è la scelta migliore per questa configurazione?
2. La perdita di potenza durante un'operazione di scrittura su disco danneggia solo periodicamente la parte di dati che sto aggiungendo al file o può danneggiare l' intero file?
3. I dati che non vengono scritti nel punto di interruzione dell'alimentazione sono completamente sicuri? In particolare, esiste il rischio che anche il mio initramfs.cpiofile possa essere danneggiato?
4. Esiste un metodo che posso usare nel mio codice dell'applicazione per proteggere i dati (ovvero creare una partizione aggiuntiva e scrivere i miei dati su immagini speculari in modo che ci siano sempre 2 copie) - la velocità non è un vero problema per la mia applicazione così costosa operazione di copia sono accettabili

Ho visto e letto le risposte a questa domanda correlata: i filesystem journaling garantiscono la corruzione dopo un'interruzione di corrente? , ma non copre del tutto alcune delle cose che mi confondono.

Mi rendo conto che sto facendo molte domande, ma sembra che nonostante abbia letto molto materiale, ho avuto un fallimento fondamentale nel comprendere i rischi per i miei dati in caso di perdita di potenza.

Come per tutte le cose relative alla sicurezza, non ci sono garanzie, ma è anche necessario bilanciare il rischio (e il costo) con la probabilità. Per esperienza (e ho eseguito decine di * nix boxen dai tempi bui), non ho mai avuto una significativa corruzione del file system causata dal potere.

Alcune di queste macchine erano persino in esecuzione su filesystem non journaled (di solito ufs ed ext2). Alcuni di essi erano integrati e alcuni erano telefoni cellulari come il Nokia N900, quindi un buon alimentatore non era affatto garantito.

Non è che la corruzione del filesystem non possa accadere, è solo che la probabilità che accada è abbastanza bassa da non preoccuparti. Tuttavia, nessun motivo per non coprire le tue scommesse.

In risposta alle tue domande letterali:

1. Almeno il primo libro a cui hai fatto riferimento è stato scritto prima ext4- quando l'autore suggerisce di usare ext3, stanno davvero dicendo 'non usare filesystem instabili o non pubblicati come ext2'). Prova ext4, è abbastanza maturo e ha alcune opzioni decenti per i dischi non rotanti che possono prolungare l'aspettativa di vita del tuo dispositivo flash.
2. È probabile che ti perderebbe l'ultimo blocco o due, non l'intero file. Con un filesystem con journaling, si tratterà dell'unica perdita. Ci sono scenari di errore in cui ho potuto vedere i dati casuali spruzzati attraverso il file, ma sembrano avere la stessa probabilità di una micrometeorite che si rompe attraverso il tuo dispositivo incorporato.
3. Vedi 2. Niente è sicuro al 100,00%.

4. Se hai un secondo canale IDE, inserisci una seconda scheda CF e prendi periodicamente un backup del filesystem. Ci sono alcuni modi per farlo: rsync, cp dump, dd, anche utilizzando il md(4)(RAID software) del dispositivo (si aggiunge la seconda unità di tanto in tanto, lasciate sincronizzazione, quindi rimuoverla - se entrambi i dispositivi sono in tensione per tutto il tempo, corrono lo stesso rischio di corruzione del filesystem). Se usi LVM, puoi persino acquisire istantanee. Per un dispositivo incorporato di raccolta dati, utilizzerei semplicemente una soluzione ad hoc che monta il secondo filesystem, copia sul registro dati, lo smonta immediatamente. Se sei preoccupato che il dispositivo abbia una buona immagine di avvio, attacca una seconda copia del gestore di avvio e tutte le immagini di avvio necessarie sul secondo dispositivo e configura il computer per l'avvio da una scheda CF.

   Non mi fiderei di una seconda copia sullo stesso dispositivo perché i dispositivi di archiviazione si guastano più spesso dei filesystem stabili. Molto più spesso, nella mia esperienza finora (al lavoro, c'era un'aspra mezza battuta sulle incredibilmente alte possibilità di guasti del disco del venerdì pomeriggio. È stato quasi un evento settimanale per un po '). Se il disco gira o no, può fallire. Quindi, se puoi, tieni le uova in due cestini e proteggerai meglio i tuoi dati.

   Se i dati sono particolarmente sensibili, farei regolari visite al dispositivo, scamberei il CF di backup con uno nuovo e riavvio, lasciando fscktutti i suoi filesystem per una buona misura.

Mi sembra che ciò che un'implementazione del filesystem può ottenere in caso di improvvisa perdita di potenza sia limitato - dopotutto, si sta effettivamente interfacciando con l'hardware, quindi cosa succede tra il momento in cui invia dati / istruzioni all'hardware e quando ottiene una risposta fuori dal suo controllo. Se esistesse un filesystem che potesse eludere questo problema, ne avresti sentito parlare.

Per questo motivo, una strategia per proteggere i dati critici trarrà maggior beneficio dalle decisioni prese a livello hardware , ad esempio, utilizzando un gruppo di continuità. Probabilmente questo non è così fattibile nella tua situazione.

Hai detto che le prestazioni non sono davvero un grosso problema, quindi fai un uso giudizioso di fsync().

La perdita di potenza durante un'operazione di scrittura su disco danneggia solo periodicamente la parte di dati che sto aggiungendo al file o può danneggiare l'intero file?

Da anni uso i filesystem extN personalmente e su server Internet a traffico medio-basso, e come Alexios non ho visto molta corruzione a causa di un'interruzione di corrente (anche se per essere onesti, i server hanno UPS e non riesco a ricordare uno di loro in realtà scende in quel modo). Un problema molto più grave è la corruzione dovuta a guasti hardware, che diversi filesystem possono (ancora) essere sempre più in grado di affrontare il problema, ma (di nuovo) questo è fondamentalmente al di fuori del loro controllo e non possono impedirlo.

Occasionalmente ho visto file persi o troncati a dimensione zero. Presumo che ci siano buone probabilità che questi siano recuperabili in qualche modo; questo non era necessario per me dato che erano stati sottoposti a backup. Il più delle volte se c'è qualcosa di sbagliato fscksembra affrontarlo.

I dati che non vengono scritti nel punto di interruzione dell'alimentazione sono completamente sicuri? In particolare, esiste il rischio che anche il mio file initramfs.cpio possa essere danneggiato?

Penso che il rischio sia davvero molto basso solo a causa di un'interruzione dell'alimentazione, ad eccezione del tipo di corruzione che l'archiviazione flash può essere soggetta a causa dell'impulso di corrente che può accompagnare le interruzioni di corrente - a cui non ho esperienza, ma spero che tu abbia pensato e ho studiato questo.

Esiste un metodo che posso usare nel mio codice dell'applicazione per proteggere i dati?

Vale la pena ripetere il punto su fsync () . Gli oggetti C ++ / iostream non hanno un metodo per questo (:: flush e :: sync non sono fsync), ma tutto ciò che serve è un descrittore di file.

ZFS è sicuramente un file system protetto dalla corruzione e probabilmente l'unico. Tuttavia, non sono sicuro della disponibilità di implementazioni ZFS (basate su fusibili o native) per piattaforme basate su uClinux.

Esiste almeno un file system commerciale che fa un lavoro eccezionale assicurandosi che il file system non possa essere quasi completamente danneggiato a causa di interruzioni di corrente e che i soli dati che si rischia di perdere siano i dati che venivano aggiunti man mano che si spegneva l'alimentazione.

Il lato negativo è che è molto costoso, sul lato positivo offrono un ottimo supporto. A causa delle spese, è davvero solo un'opzione per quote alte e / o prodotti ad alto volume. Come le apparecchiature critiche integrate, ad esempio nella produzione di petrolio e gas, che devono garantire l'integrità del sistema in condizioni operative "incerte" (ad es. Frequenti interruzioni di corrente, ecc.).

Dai un'occhiata a DataLight (azienda) e / o al prodotto " Reliance NITRO ". (Reliance è la loro soluzione legacy e sicura ma non molto efficace, sostituita da Reliance NITRO ). Anche se non hai soldi per usare questo sistema, hanno alcuni articoli abbastanza buoni che parlano di come funziona il loro sistema, perché è più affidabile di ext3 e ext4.

Mi scuso se questo ha letto come un annuncio, volevo solo sottolineare le opzioni.