Newsgroup: it.comp.os.linux.development
Titolo: [Forse OT] Controindicazioni nell'installare il SO sule memorie allo stato solido

Salve a tutti,
  spero di non essere OT, posto qui perchè diverse volte ho visto thread 
interessanti sull'embedded linux.
In pratica sto pensando di installare una versione di Linux "normale", 
pensavo una Debian su un PC del tipo mini-itx, però per vari motivi non 
posso utilizzare un disco fisso normale e quindi pensavo di usare una 
Compact Flash da 4GB con un adattatore IDE.
Quello che mi preoccupa è il massimo numero di riscrittore gestite da 
queste memorie, mi pare intorno alle migliaia.
So che esiste un file-system sviluppato apposta per queste memorie 
proprio per limitare il problema ma non lo ho mai usato e pertanto 
vorrei chiedere qui se qualcuno lo utilizza in ambiti seri e se è 
affidabile.
O forse è megli usare i soliti Reiser e Ext3? Hano lo stesso problema 
della FAT riscritta ad ogni modifica del file-system tipica di Windows?
Non è che mi faccio troppi problemi e il problema è superato dalle 
tecnologie attuali? In fondo le chivette USB sono in FAT16 e non hanno 
problemi particolari...
-- 
Saluti, Ledom            (Per le mail il server corretto e' 
gmail.com
)
Eh, ai miei tempi era tutto diverso... gli uomini erano veri uomini, le 
donne vere donne e i byte veri byte.

 proprio per limitare il problema ma non lo ho mai usato e pertanto 
Parli di ROMFS? Credo nasca per altri utilizzi.
Quello che vuoi fare tu lo fai con EXT2 (il 3 non serve, risparmi spazio
e CPU) e qualche accortezza: montare su ramdisk le directory dove e'
previsto ci si debba scrivere col sistema in opera.
Ovvero /tmp e tutta o una selezione di /var su ramdisk, il resto
montato direttamente ro. 
Poi dipende da quello che ci devi fare. :)
	approssimatamente,
	    Cthulhu
-- 
http://www.rlyeh.it/Rantolii/

 montato direttamente ro. 
quoto, io li uso spesso per lavoro (i Disk On Module) e la tecnica è
proprio questa.
Se poi devi memorizzare qualcosa, lo fai alla fine , magari mettendo le
direttive di scrittura nello script di shutdown.
ciao

 problemi particolari...
Beh, le chiavette andrebbero montate anche quelle con noatime ;) Tieni
conto che la FAT e` particolarmente semplice come FS, quindi in caso di
shutdown "sporco" e` facile che ci siano corruzioni e che queste non
vengano neppure rilevate... se ti capita sulla chiavetta USB formatti e
ci rimetti i tuoi mp3 preferiti, se ti capita sul tuo dispositivo che
non riesce piu` a fare il boot capisci che e` un po' piu` grave...
Luca
-- 
Home: 
http://kronoz.cjb.net
E' stato a causa di una donna che ho cominciato a bere e non ho mai
avuto la cortesia di ringraziarla.

 JFFS2? Si`, e` stabile e affidabile. Di solito poi la /tmp e` un
Pero' JFFS2 funziona solo su MTD, non su block devices. E una CF da 4GB
su adattatore IDE non e' MTD.
Il tutto AFAIK, o e' cambiato qualcosa negli ultimi tempi e c'e' stata
una convergenza? :)
	curiosatamente,
	   Cthulhu
-- 
http://www.rlyeh.it/Rantolii/

 su adattatore IDE non e' MTD.
Mi ero perso la parte dell'adattatore IDE ;) In questo caso il
controller della flash dovrebbe implementare qualche algoritmo di wear
leveling.
Luca
-- 
Home: 
http://kronoz.cjb.net
Non ho ancora capito se il mio cane e` maschio o femmina:
quando fa la pipi` si chiude in bagno

 leveling.
Adesso non cominciare a parlare complicato. :)
	incomprensibilmente,
	     Cthulhu
-- 
http://www.rlyeh.it/Rantolii/

 Adesso non cominciare a parlare complicato. :)
Vuol dire che il controller internamente mappa un blocco logico (quello
che vede l'OS) su un blocco fisico (quello che c'e' sulla flash) usando
un qualche algoritmo che minimizzi il numero di riscritture sullo stesso
settore fisico.
Luca
-- 
Home: 
http://kronoz.cjb.net
"L'ottimista pensa che questo sia il migliore dei mondi possibili. 
 Il pessimista sa che e` vero" -- J. Robert Oppenheimer

ciao,
inoltre, da quel che so, JFFS2 e' ottimizzato per dimensioni
dell'ordine dei mega (fino a qualche centinaio): se vai
sui Giga, inizia ad avere un eccessivo overload di
tabelle di gestione varie.
Se non ricordo male e' in sviluppo, ma non so a che punto
JFFS3: da verificare se supera questo problema.
ciao
giammy
P.S: ovviamente niente swap su flash :-)
--
Gianluca Moro          
http://groups.yahoo.com/group/embeddeditalia/
ISCRIVITI alla         Mailing List Italiana su LINUX EMBEDDED
giang...@yahoo.com
   Visit 
http://ilpinguino.altervista.org/

 settore fisico.
Appunto, visto che già le compact flash integrano parecchia elettronica 
che permette di gestire la memoria come se fosse un disco IDE non mi 
pare troppo complicato implementare anche un algoritmo simile.
Ho provato a cercare qualche data sheets con Google ma trovo solo roba 
"commerciale" senza nulla di utile al riguardo, però molte schedine come 
Kingstom sono garantite a vita, sarebbe un bel rischio se dopo 2/3 mila 
scritture fossero inutilizzabili soprattutto considerato che usano quasi 
sempre la FAT16 che per ogni modifica riscrive la tabella di allocazione.
Stavo quasi pensando di sacrificare una schedina da 64 MB che ho 
inutilizzata per farci qualche test e vedere se dopo qualche migliaio di 
scritture getta la spugna ma non sono affatto sicuro che quello che 
valga per una scheda sia generalizzabile considerenda anche che la mia 
schedina è vecchia e la tecnologia si evolve rapidamente.
Se qualcuno conosce link tecnici magari a dei data sheets veri mi 
farebbe un favore.


 P.S: ovviamente niente swap su flash :-)
Beh, a questo ci ero arrivato anch'io ;-)
Pensavo di disabilitarlo del tutto.


 interessanti sull'embedded linux.
mi sembra che esista una patch per le union mount, con cui puoi montare
un filesystem readonly assieme ad un ramdisk.
prova a dare un'occhiata in google, perche' e' un vago ricordo, non una
certezza.

 un filesystem readonly assieme ad un ramdisk.
Esiste Unionfs e mi pare che sia usato da Knoppix:
http://unionfs.filesystems.org/