Newsgroup: it.comp.os.linux.sys
Titolo: memoria flash e ext3, comportamento stranissimo

a lavoro è succesa sta cosa e nn so veramente da che parte cominciare per
capire quello che succede.
Allora, abbiamo delle macchine dove il FS è memorizzato su flash
(all'avvio una parte va in ramdisk, e la parte che sappimo che non deve
cambiare resta sulla flash in ro)
Praticamente in flash restano per la lettura file video (avi), flash(swf)
ed alcune bitmap.
Periodicamente viene fatto un controllo suull'integrità dei file di
questo tipo:
calcolo della crc (16 a bit) e confronto della stessa calcolata su gli
stesi file residenti in un server di produzione. sS la crc cambia è
successo qualcosa (file corrotto) => ricaricare il file sull'apparecchio.
Adesso arriva il punto critico: visto che questa crc cambiava un po'
troppo spesso su troppi apparecchi, sono andato a controllare cosa succede
effettivamente  non c'ho capito una mazza!
Effettivamente il file incriminato ha la crc diversa, me lo scarico sul
computer in locale e questa continua ad essere diversa , faccio un
confronto byte a byte col file integro e noto che ben 1022 byte
(contigui) differiscono per valore , ecco un estratto di cmp sui due file:
244737 137 253
244738  54 103
244739 125 357
244740  56 276
244741 105 157
244742 306  47
244743   3  63
244744 375  53
244745 275 242
244746 335  26
244747 341 306
244748 111 210
244749  72 322
insomma in una situazione del genere viene da dire "ok il file è corrotto
va rimandato", ma ...attenzione attenzione
se provo a fare play sul file questo funziona perfettamente (parlo di un
swf, formato del quale non conosco le specifiche)
ma soprattutto: se riavvio l'apparecchio (quello iniziale dove il file
risiede in flah memory)... il file ritorna ad essere senza errori!!!
Questa cosa non me la spiego proprio, insomma ad un certo punto
(totalmente casuale ) dopo un riavvio il file ha questi 1022 byte di
differenza che tornano ad essere del loro valore originale dopo un altro
riavvio. Poi magari dopo qualche altro riavvio succede che l'errore si
ripresenta, e cosi' via.
Al che ho provato a simulare sul disco cosa succede al riavvio ed ho avuto
lo stesso comportamento:
umount partizione
mount partizione
tac, il file torna sano!
Ecco il problema è questo, e non ho idea di cosa
tentare per rimediare.
la partizione è una ext3 montata così
/dev/hda2       /usr/local/data ext3 ro,auto,sync
ogni tanto puo' capitare di dover scrivere sul FS , quindi si rimounta la
partizione in rw per rimontarla subito dopo in ro
cosa puo' accadere al FS in fase di mount per cui possa succede questa
roba?
grazie a chiunque possa essermi minimamente d'aiuto, io brancolo nel buio

 roba?
Fortuna con la C maiuscola?
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname
http://bitsandchaos.wordpress.com

 Fortuna con la C maiuscola?
:-)
garzie per l'interessamento
Andrea

 potresti essere piu' chiaro su questo punto? grazie
Ciao,
montandola con noatime disabiliti l'aggiornamento degli "access times" 
sugli inode;
ti risparmi così una scrittura per ogni lettura di un file.
Ma se la partizione è montata in ro, non ne vedo molto l'utilità!
G.

 Ma se la partizione è montata in ro, non ne vedo molto l'utilità!
 
è quello che ho pensato anche io, forse lui si riferiva al fatto
che tanti remount possano essere la causa di una riduzione della
durata delle flash? (e perchè mai?)

 potresti essere piu' chiaro su questo punto? grazie
Monta la partizione con noatime se puoi.


 ...
I processi di scrittura e di lettura per una memoria flash 
sono asimmetrici; la scrittura e` molto piu` lenta, avviene 
per blocchi ed impiega tensioni piu` alte. Queste tensioni 
piu` alte a lungo andare danneggiano l'isolante dei MOS; si 
stima che una flash NOR sopporta 100000 cicli di scrittura
mentre una NAND ne sopporta 1000000. E` stato calcolato 
scrivendo ripetuitamente una flash NAND alla massima 
velocita` questa potrebbe durare circa cinquant'anni.
Comunque usare ext2/ext3 stressa molta le memorie flash 
poiche` questi modificano continuamente le metainformazioni 
negli inode con piccole scritture (pochi byte alla volta).
Per questo si consiglia di non formattare le memorie flash 
con ext2/ext3 e nel caso specificare le opzioni noatime 
o montare in sola lettura. 
Esistono filesystem specifici per flash drive ma (pare 
strano) la scelta migliore per formattare una penna USB e`
ancora FAT.

 la causa di una riduzione della durata delle flash? (e perchè mai?)
Perche` il montaggio di un filesystem ext2/ext3 comporta la modifica 
dei superblocchi; vengono aggiornati il conteggio dei mount, la data 
del mount, alcuni flag e cosette simili.
Comunque credo che si riferiva alla prima ipotesi.

 durata delle flash? (e perchè mai?)
No, mi riferivo al fatto che (ho capito che) ogni tanto la monti anche in
scrittura. In quei casi noatime aiuta.


 scrittura. In quei casi noatime aiuta.
capito, anche se in verità la monto, ci copio un file, e la smonto.
in ogni caso è un valido consiglio
grazie

 Che la memoria di massa si sta rompendo.
mi andrebbe bene, ma il fatto che questo errore scompare se smonto e
rimonto il device, mi lascia perplesso...
ciao

 Comunque credo che si riferiva alla prima ipotesi.
si č spiegato dopo 
ma che ne pensi di errori che scompaiono al successivo mount?

 ma che ne pensi di errori che scompaiono al successivo mount?
Secondo me sei incappato in un loop di settori difettosi del supporto.
Le flash moderne hanno un sistema che rimappa i settori difettosi su 
settori liberi del supporto, oltre a rimappare continuamente i settori in 
scrittura per evitare di danneggiare il supporto per troppe scritture.
Puo` essere che questo sistema rilevi alternativamente che il settore del 
file che al mount e` corretto, si stia corrompendo, quindi lo mappi su un 
settore corrotto, copiandoci il salvabile dal blocco originale. Dopo un 
po' si accorge che anche il secondario e` corrotto e lo rimappa sul 
primario, ecc. ecc.
Quando mappa da una parte il mdsum e` corretto, quando mappa dall'altra 
no. Al mount mappa sempre il primario e funziona.
Prova a sostituire la flash e fai un po' di test su questa che da` 
problemi.
Bye.

 ma che ne pensi di errori che scompaiono al successivo mount?
Non ho capito se il problema capita per un solo file su una 
sola macchina oppure e` generalizzato.
Nel primo caso credo sia una flash difettosa; cambiala o provala 
su un'altra macchina.
Nel secondo caso non saprei proprio.

 Nel secondo caso non saprei proprio.
manco io :(

 manco io :(
Ho risolto il problema!
Una spia senza scrupoli si e` disfatta di un etto di polonio
210 gettandolo in un container destinato ad una fabbrica di
flash memory ed e` finito casualmente in una partita delle 
stesse destinate ad essere vendute in Italia.
Il polonio non e` pericoloso ma causa di tanto in tanto delle 
emissioni di raggi gamma che alterano l'output delle memorie 
ma non i dati memorizzati nelle memorie.

 rimonto il device, mi lascia perplesso...
Non ti e' mai capitato con un CD?


 risiede in flah memory)... il file ritorna ad essere senza errori!!!
Corruzione della page-cache. Stai usando un ARM o comunque
un'architettura con cache ad indirizzi virtuali? Di solito il problema
si presenta quando manca un flush della dcache da qualche parte ;) Certo
il tuo caso mi sembra molto plateale... sarebbe stato notato da tempo.
E' escluso un problema hardware? Prova a compilare un kernel con "Debug
VM" (DEBUG_VM) e soprattutto "Debug slab" (DEBUG_SLAB); il kernel sarà
visibilmente più lento, ma un'eventuale corruzione dovrebbe venir notata
abbastanza in fretta (sempre che non sia esclusivamente relegata alla
page cache...)
Luca
-- 
Sono un mirabile incrocio tra Tarzan e Giacomo Leopardi.
In me convivono tutte le doti intelluttuali di Tarzan e
tutta la prestanza fisica di Giacomo Leopardi.
A. Borsani