sopravvivere al power-loss

Non ho esperienze di un ambiente così stretto ma ext3 mi sembra più indicato dato che ha il journaling.

Il 27/02/2011 8.15, Andrea D'Amore ha scritto:

journaling: più probabilità di recupero in caso di corruzione ma anche più probabilità di incappare in una corruzione avendo continue necessità di loggare... in abbinamento ad una cf il journaling non lo ritengo molto valido

-ice-

La CF hai detto che sarebbe comunque usata in ro, la ext3 la intendevo per lo storage sul bus USB. Il journaling segna le intenzioni di modifica prima delle modifiche e dato che parli di powerloss mi sembra opportuno avere uno strumento in più per diagnosticare un eventuale problema. Non so che tipo di dati tu debba salvare sulla memoria flash o se siano critici ma non puoi dotare il sistema di un gruppo di continuità che gli dia il tempo di chiudere il fs correttamente?

Che alimentazione usa? Se avessi una singola linea, per esempio 12V, potresti metterci una batteria tampone, rilevarne la mancanza di corrente a monte e pilotarci lo shutdown pulito. Con alimentazione ATX o simili è un po' più complicato, ma per quello ci sono gli UPS già pronti.

"ice" ha scritto nel messaggio news:1jmap.227$% snipped-for-privacy@twister1.libero.it...

se il tipo di dati che devi memorizzare te lo consente, fai in modo che il file di log sia di lunghezza fissa (ossia la massima), questo fara' in modo che il SO non debba aggiornare nulla di critico nel FileSystem. questa tecnica, nel mio caso, ha funzionato su normale FAT con DOS come OS , ma era un RAMdisk e non una chiavetta usb.

Un bel giorno ice digitò:

Con journaling filesystem si intende un FS nel quale gli aggiornamenti sono eseguiti in maniera atomica, ed è quindi intrinsecamente protetto dalle corruzioni. Il problema dei journaled FS usati con i MTD è che necessitano di un numero di scritture molto più alto, e se la memoria non è dotata di un buon algoritmo di wear leveling ciò può accorciarne la vita. Comunque le buone CF industriali (Sandisk, PQI, ...) hanno ottimi algoritmi di wear leveling, ho usato NTFS su CF Sandisk per mesi e mesi senza problemi. Puoi ulteriormente migliorare le cose concentrando le scritture (scrivi molti dati poco frequentemente anziché pochi dati molto frequentemente) oppure, se il kernel te lo consente, allungando il tempo di "lazy write" (il tempo oltre il quale il kernel scrive i dati che sono ancora nella cache di scrittura).

Ovvio che se la tua applicazione richiede un carico di lavoro *davvero* gravoso, è il caso di sottoporre prima la CF a un ciclo di vita accelerato per vedere come si comporta.

cerco una soluzione senza ups o batterie tampone... troppo facile :)

-ice-

Il 27/02/2011 10.09, Andrea D'Amore ha scritto:

ok

ok; come dicevo però i dati raccolti non sono critici... avevo pensato ad ext2 per non pregiudicare la durata della flash

no :)

-ice-

Il 27/02/2011 19.06, dalai lamah ha scritto:

anche usando il journaling non riesci ad essere atomico in senso stretto su una cf perchè per scrivere 1 settore devi riscrivere molti più dati impiegando decine di ms; tra l'altro parte dei dati la logica della compact-flash non li scrive su "flash" subito ma li bufferizza

oppure,

intendi il parametro "swappiness"?

non richiede carico gravoso; non posso accettare però di trovarmi con il filesystem del sistema operativo corrotto a seguito di una banale interruzione di corrente

grazie anche a te;

-ice-

Un bel giorno ice digitò:

Non importa; il principio è simile a quello dei DBMS, ogni modifica sebbene sia composta da varie scritture viene "chiusa" dall'ultima operazione, idealmente dall'ultimo settore scritto. Se l'ultima scrittura fallisce, la modifica è completamente annullata.

No, credo che quello riguardi lo swap file anziché la memoria virtuale nel suo complesso (i due concetti non sono sinonimi). Piuttosto puoi partire da questo articolo:

Questa parte l'ho letta dopo avere scritto la risposta precedente: riguardo al sistema operativo, è buona norma metterlo su una partizione readonly come ti hanno già spiegato. Oppure usare tecniche come queste (che sicuramente esisteranno anche per Linux):

In sostanza si tratta della massima estremizzazione del concetto di memoria virtuale: tutte le modifiche fatte a un filesystem restano in RAM e al massimo puoi forzare un "mega-commit" alla fine per applicarle tutte assieme. Oppure se non ti servono le puoi perdere e ripartirai sempre dal punto di partenza.

il mio dubbio =E8 legato al fatto che per il sistema operativo la "commit" ha successo perch=E8 tutti i dati da scrivere sono stati passati alla logica del supporto fisico (la compact-flash) questa per=F2 non li ha fisicamente scritti *tutti* sulla memoria flash ma li ha bufferizzati in ram (una sua ram interna intendo) per poi traferirli su flash (flush) nei milli-secondi successivi; se manca alimentazione in questo frangente che succede?

ora lo leggo

riguardo

si, mi sto documentando; il problema =E8 che non si riesce a mettere tutto read-only

in pratica il concetto di una distribuzione live di gnu/linux?

nel mio caso potrebbe anche andarmi bene; parto sempre con un sistema fresh ed eventuli settaggi utete posso andarli a memorizzare sulla chiavetta usb esterna, dove memorizzo anche i dati raccolti; in caso di problemi perdo quelli ma la macchina non =E8 ferma per una corruzione del filesystem

grazie

-ice-