File system che non si interrompe mai (perdita di dati accettabile)

Ci sono molti argomenti esistenti che ruotano attorno a questo problema, ma quello che cerco è leggermente diverso. Ho una scheda SD su un Linux incorporato e soffre di perdita di potenza. Potrei essere in grado di modificare l'hardware ad un certo punto, chiuderlo correttamente e così via, ecc. Ma in questo momento, vorrei solo trovare un file system che sopravviva alla perdita di potenza senza problemi. La perdita di dati è accettabile. Preferirei non perdere più del file che sto scrivendo, ma preferirei comunque perdere tutto piuttosto che affrontare un 'incapace di montare', 'attendere questi 10 minuti fsck' o 'incapace di crearne di nuovi file a causa di questo inode qualcosa errore '. Il programma DEVE proseguire!

Mi sto impegnando molto per garantire questo. Sto usando componenti di livello industriale, ho cani da guardia hardware, cani da guardia software, interni, esterni, init riavvia i programmi, demoni controllano costantemente la memoria, descrittori di file e quant'altro, ho cani da guardia che guardano i miei cani da guardia, che a loro volta sono guardati da altri cani da guardia ... Ma non riesco a garantire che la scheda SD sia in grado di montare e funzionare?

La mia scommessa migliore in questo momento, è usare JFS sulla scheda SD, includere fsck e fsck.jfs nella mia installazione. (Aggiungendo 600kb + mangiando il mio ram e il mio flash. Il che è male.) Ed esegui fsck ad ogni avvio (forse aggiungendo molto tempo di avvio. Che è un po 'male.). Sembra un po 'triste però.

Qualcuno sa un modo migliore o un file system migliore?

AGGIORNAMENTO: e2fsprogs-libs (dipendenza da jfsutils) sembra essere incredibilmente difficile da compilare nella mia distribuzione. Esaminerò ZFS (non è nativo della mia distribuzione però. E sembra fare molto di cui non ho bisogno.)

AGGIORNAMENTO2: Qualche informazione in più sul mio sistema e sui miei test: la memoria della scheda SD è una memoria secondaria opzionale. Le schede SD sono microSD di livello industriale da 2 Gb-8 Gb. La scheda SD è montata attraverso il mio rc con un comando mount -t. Opzioni "noatime" ma non "sync". La mia distribuzione è un uClinux personalizzato basato sul dispositivo analogico, con un kernel 3.10 e una busybox 1.21. La mia memoria principale è un flash spi con jffs2. Non ho mai avuto problemi con questo. Non so nemmeno se è disponibile un fsck.jffs2. Nand flash d'altra parte ... ma questa è una storia diversa. Lo scopo della scheda SD è di memorizzare i dati di misurazione. Il programma "monitor" aggiungerà i risultati a un file e avrà posizionamenti di sincronizzazione strategici. Quando il file supera una determinata dimensione, ne verrà creata una nuova. Quando viene raggiunto un determinato numero di file, quello più vecchio verrà eliminato. Se il file di misurazione corrente viene perso a causa della perdita di potenza, non è un disastro. I file sono in genere a 50-100 kb e 1 risultato è in genere 1 kb. Questa è solo la fase iniziale di sviluppo. Niente è stato risolto. Questa è la prima volta che mi occupo di filesystem non flash nei sistemi embedded. (Ho ottenuto ext4 sui miei server x86.)

Ho iniziato con vfat. Il filesystem predefinito. (Ho pensato che le fabbriche potrebbero avere un motivo per sceglierlo. E se le cose funzionano non mi interessa molto.) Non ho mai visto problemi di perdita di potenza nei miei dispositivi vfat incorporati. Tuttavia, ho riscontrato problemi con FAT in WinCE. Tuttavia, quando il mio programma "monitor" ha raggiunto i 100-200 file, si è rifiutato di crearne altri. Sembra che FAT abbia un problema con il limite di file speciale nella radice e uno leggermente più grande nelle directory secondarie. Devo essere in grado di creare 500-1000 file in 1 dir. Quindi vfat non lo farà.

Quindi sono passato a ext2. Tuttavia non ho inserito un fsck all'avvio. (Non sapevo che dovevo farlo.) Nel giro di un giorno il mio programma "monitor" non è stato in grado di creare più file a causa di un errore "inode qualcosa". Disastro!

La mia soluzione attuale è ext2 con un "e2fsck -y" all'avvio. Finora sembra promettente. Ma l'e2fsck e l'intero concetto di "fsck all'avvio" mi tormentano. L'e2fsck da solo sta spendendo più di 350kb del mio flash e ram primario. (Quando non è in esecuzione.) Il che significa che è il mio programma più grande. È più grande di busybox. Sta quasi rivaleggiando con il mio kernel.

Ho preso in considerazione ext3. Ha pubblicato metadati, che non farebbero male. Sono in dubbio su quanto aiuterà comunque. Con i miei piccoli file e le sincronizzazioni controllate dovrei essere coperto, penso? Ha una sequenza di scrittura ordinata. Ciò significa che anche i dati sono in qualche modo registrati. Ciò tuttavia può portare a ritardi non deterministici. Il che è brutto nella mia situazione. (Probabilmente non è un problema.) Ha anche una funzione di sincronizzazione pianificata. Per esempio. commettere ogni 5 sec. Il che sta interferendo con le mie sincronizzazioni, penso. Troppe scritture sono dannose per le schede SD. Anche quelli industriali. Non riesco a trovare alcuna documentazione su come disabilitarlo. E ext3 richiede ancora che fsck sia eseguito ad ogni avvio! Ext3 è ancora una possibilità.

Ext4. Risolverà molti problemi di prestazioni di ext3. Non ho davvero bisogno di prestazioni però. E la mia distribuzione non sembra avere un mkfs.ext4 incorporato e un fsck.ext4. Forse non è un problema. Potrebbe però. Per esempio. le librerie e2progs (dipendenza da jfsutils) sembrano avere molti problemi di compilazione.

JFS, XFS, BRFSS. Tutto supportato dal mio kernel. Attualmente non incluso nella casella degli strumenti del mio spazio utente. Tutto sembra essere un sistema piuttosto grande e complesso. E tutti sembrano richiedere un equivalente "fsck" all'avvio?

Ho anche pensato di lanciare il mio filesystem: scrivi sempre 2 copie della tabella dei file. Durante l'attraversamento, seleziona quello con il CRC corretto e il numero di sequenza più recente. Crea una sequenza di scrittura in 2 fasi. Assegna temporaneamente, correggi al commit. Non è necessario fsck. Temo che potrebbe essere un po 'ingenuo.

UPDATE3: A proposito, la natura dei sistemi embedded (almeno questo) è che sono autonomi, incustoditi, fuori portata e devono funzionare per anni. Programmi come fsck che potrebbero richiedere l'interazione umana mi spaventano.

C'è un po 'di incoerenza o almeno, ambiguità, nella tua storia qui:

Preferirei comunque perdere tutto piuttosto che affrontare un 'incapace di montare', 'aspettare questi 10 minuti fsck'

Implica, anche se in realtà non lo dici, che questo è un problema che stai effettivamente riscontrando. Ma allora:

e2fsprogs-libs (dipendenza da jfsutils) sembra essere incredibilmente difficile da compilare nella mia distribuzione.

Significa che non hai affatto fsck , poiché e2fsprogs-libsè una dipendenza per e2fsprogscui fornisce e2fsck. Quindi forse sei ancora in una fase di pianificazione qui e non hai nemmeno testato il sistema, ad esempio ext4, ma invece sei arrivato alla conclusione che dovresti iniziare con JFS? C'è qualche motivo particolare per questo?

Ho notato sullo scambio di raspberry pi (la memoria principale del pi è anche una scheda SD) che un numero significativo di utenti sembra essere molto frustrato da problemi di questo tipo, anche se la maggior parte (incluso me stesso) non ha mai avuto tutti. Inizialmente ho pensato che si trattasse di persone ignoranti del fatto che il sistema dovrebbe essere chiuso in modo pulito, ma non è un punto difficile da comprendere quando spiegato, e ci sono persone che lo segnalano anche se il sistema è stato chiuso correttamente .

Hai già detto che ti serve questo per essere in grado di tollerare interruzioni di corrente (il che è abbastanza giusto), ma lo menziono perché implica che ci sono alcuni pis, alcune schede SD o una combinazione di entrambi, che sono solo inclini a corrompere il filesystem a causa di un evento (impennata?) che si verifica regolarmente o quando viene rimossa la spina, o quando viene rimessa a posto. Inoltre NON ho visto - e c'è stato un sacco di tempo per provare un sacco di gente - QUALSIASI notizia di qualcuno che dice di essere passato a btrfs o jfs o qualsiasi altra cosa e ora il problema è risolto.

L'altra cosa misteriosa a riguardo è che, anche se le persone strattonano il cavo, ciò non dovrebbe comportare regolarmente un filesystem inutilizzabile. Certamente l'ho fatto un sacco di volte con il pi, e segna se non centinaia di volte con un normale box Linux (il potere è stato interrotto, il sistema è diventato non rispondente, sono esausto e arrabbiato, ecc.) e mentre ho visto una piccola perdita di dati, non ho mai visto un filesystem corrotto al punto da essere inutilizzabile dopo un rapido fsck.

Ancora una volta, supponendo che tutti questi rapporti siano veri (non vedo perché un numero di persone mentirebbe al riguardo), c'è qualcosa di molto più in atto rispetto al semplice non smontaggio, ma sembra influenzare solo una piccola percentuale di utenti, implicando di nuovo qualche tipo di difetto hardware comune.

Sul pi greco Scrivo -ya /forcefsckin uno script di avvio, in modo che al successivo avvio viene eseguito automaticamente e gli eventuali problemi sono fissi, indipendentemente dal fatto che questo sembra essere necessario o meno. Su un single core da 700 Mhz sono necessari ~ 10 secondi per un filesystem da 12 GB contenente ~ 4 GB di dati. Quindi "10 minuti" sembra un tempo incredibilmente lungo, soprattutto perché hai già detto "Questo è il piccolo filesystem per scrivere!".

Potresti anche considerare di chiamare synca intervalli regolari.

Infine, dovresti aggiornare la domanda con dettagli più concreti e specifici sui problemi che hai effettivamente riscontrato e meno iperbole. Altrimenti sembra troppo un problema XY prematuro , che probabilmente verrà rapidamente ignorato da persone con molta esperienza e potenziali consigli per te.

Il programma DEVE proseguire!

Bene, questo è un requisito comune e i sistemi Linux sono la scelta migliore quando si tratta di scegliere un sistema stabile.

Anche i tuoi sforzi sembrano non andare nella giusta direzione. Tuttavia, cosa puoi fare per ottenere un sistema stabile?

Nel primo livello puoi migliorare il tuo file system:

• Utilizzare yournal_data_orderedsu un ext3/ext4filesystem, quando si crea o si modifica con tune2fs.
• Con l' JFSuso --replay_journal_onlydurante il controllo.
• Abilita autorepair impostando FSCKFIX=yesinitscripts.

Se ciò non bastasse, è possibile avviare il sistema senza montare il disco con errori. Invece creane uno nuovo ramdiskmentre controlli e ripari manualmente il tuo disco difettoso. Questo può anche essere automatizzato da script.

Nel livello successivo dovrai lasciare il tuo sistema incorporato e leggere alcuni argomenti sull'alta disponibilità