Domanda

Abbiamo un certo numero di sistemi embedded che richiedono r/w accesso al filesystem che risiede sulla memoria flash del dispositivo a blocchi di emulazione.I nostri più antichi piattaforma gira su compact flash e questi sistemi sono stati utilizzati per più di 3 anni senza un singolo fsck essere eseguiti durante l'avvio e finora non abbiamo guasti attribuiti al filesystem o CF.

Sulla nostra nuova piattaforma abbiamo usato flash USB per la produzione iniziale e ora la migrazione di Disk-on-Module per r/w di stoccaggio.Qualche tempo fa abbiamo avuto alcuni problemi con il filesystem su un sacco di dispositivi in esecuzione su USB-storage così ho abilitato e2fsck per vedere se che sarebbe di aiuto.Come si è scoperto che aveva ricevuto una spedizione di bad flash di memoria in modo da una volta che questi sono stati sostituiti il problema è andato via.Allora ho disabilitato e2fsck dal momento che abbiamo avuto alcuna indicazione che il sistema più affidabile e storicamente siamo stati bene senza di essa.

Ora che abbiamo iniziato a mettere in Disk-on-Module unità ho cominciato a vedere filesystem errori di nuovo.Improvvisamente il sistema è in grado di leggere/scrivere alcuni file e se provo ad accedere al file dal di emergenza console ottengo solo "Errore di Input/output".Ho abilitato e2fsck di nuovo e tutti i file sono stati corretti.

O'Reilly "Costruzione Di Sistemi Linux Embedded"raccomanda di eseguire e2fsck sul filesystem ext2 ma non fa menzione di esso in relazione a ext3 quindi sono un po' confuso se devo attivarla o meno.

Quali sono i tuoi assume l'esecuzione di fsck su un sistema embedded?Stiamo pensando di mettere su binari a r/o partizione e solo il file che deve essere modificata su una r/w partizione sullo stesso dispositivo flash in modo che fsck non può mai eliminare accidentalmente importanti binari di sistema, qualcuno ha qualche esperienza con questo tipo di installazione (buono/cattivo)?

È stato utile?

Soluzione

Penso che la risposta alla tua domanda si riferisce più a che tipo di coerenza dei requisiti di applicazione è relativa ai suoi dati.Che è, ciò che deve essere garantita in caso di perdita di potenza senza un formale di arresto del sistema?In generale, nessuno di sistema operativo desktop tipo di sistemi di file di gestire questa che, senza applicazioni specifiche di chiusura/sincronizzazione di file e arrossamento della cache del disco, etc.in chiave di transazione punti dell'applicazione per garantire ciò di cui avete bisogno per mantenere la è, infatti, impegnata nella media.

L'esecuzione di fsck corregge i file di sistema, ma non cura, non c'è alcuna garanzia su ciò che le modifiche apportate saranno effettivamente mantenuto.vale a dire:Non è esattamente deterministico che cosa si perde come risultato della mancanza di alimentazione.

Sono d'accordo che mettere il vostro file binari o altri importanti dati di sola lettura su una lettura separata-la partizione di non fare in modo che essi non possono, erroneamente, di avere gettato a causa di un fsck correzione per i file di sistema di strutture.Come minimo, metterli in una sotto-directory principale di dove R/W dati, sarà di aiuto.Ma in entrambi i casi, se si supportano gli aggiornamenti del software, devi comunque avere regime di trattare con la scritta "read-only" aree comunque.

Nella nostra applicazione, abbiamo effettivamente mantenere un paio di directory per cose come i binari e il sistema è configurato per l'avvio da uno dei due aree.Durante l'aggiornamento del software, si aggiorna la prima directory di sincronizzazione di tutto per la media e verificare il checksum MD5 sul disco prima di passare la seconda copia di aggiornamento.Durante l'avvio, vengono utilizzati solo se il checksum MD5 è buona.Questo assicura che si sta avviando una immagine coerente sempre.

Altri suggerimenti

Dave,

Ho sempre consigliabile eseguire fsck dopo una serie di riavvii, ma non ogni volta.

Il motivo è che, ext3 è giornale-ed.Quindi a meno di non consentire la ripresa di valore (gazzetta meno), quindi la maggior parte del tempo, i metadati/file di sistema tabella deve essere in sincronia con i tuoi dati (file).

Ma come ha già detto Jeff, non garantisce il livello sopra il file di sistema.Significa, è ancora ottenere il "corrotto" i file, perché alcuni dei record, probabilmente non si è scritto nel file system.

Io non sono sicuro di quello incorporato dispositivo che si sta eseguendo, ma come spesso viene riavviato?Se è controllato riavvio, si può sempre fare "sync;sync;sync" prima di riavviare.

Ho usato il CF di me per anni, e molto rara occasione ho avuto gli errori del file system.fsck non aiuto in questo caso.

E la separazione della partizione, dubito che il vantaggio di esso.Per tutti i dati/file nel file di sistema, c'è un metadati associati con esso.La maggior parte del tempo, se non si modifica il file, ad esempio.binary/file di sistema, quindi questo metadati non dovrebbe cambiare.A meno che non si dispone di un guasto hardware, come il cross-talking di scrittura e di lettura, quelle file di sola lettura dovrebbe essere al sicuro.

La maggior parte dei problemi nasce quando si ha qualcosa di scritto, e indipendentemente da dove si mette questo, può causare problemi se l'applicazione non gestisce bene.

Speranza che aiuta.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top