salut,

j'ai un petit projet de matériel embarqué, et je veux faire un système solide pour profiter de la compact flash et d'une grande capacité en RAM.

sur un PC classique, 512Mo de ram me suffisent amplement. je peux donc allouer les 512Mo restant d'une mémoire RAM 1Go pour le système, en enlevant ce qui prend trop de place ( /home entre autre) et qui ne demande pas trop d'accès. (besoin de conseil à ce sujet)

la carte mère utilisée est celle-ci :

http://www.thinkitx.com/j8f9-800_a [...] 0-1-c.html

je ne sais pas encore quelle carte CF je vais utiliser. ça va surtout dépendre de mes finances.

voici le démarrage du système tel que je l'imagine :

-POST   |_ ça va sûrement changer avec coreboot
-GRUB   |
- chargement du kernel
-chargement des ressources
-chargement du système en RAM (hormis certain pré-sélectionné)
-startx

le transfère des données de la CF vers la RAM se fait en passant par le chipset (cannal IDE) puis via le geodeLink (qui relie simplement le chipset au CPU), puis enfin via le contrôleur mémoire intégré au CPU vers la RAM. ça ne va pas me faire perdre en performances (du moins au boot, lors de la copie) ?

pour la CF, je compte utiliser le système de fichier jffs2, permettant de protéger la mémoire FLASH des écritures/lectures locales trop nombreuses. seulement il semble que certaines mémoires gèrent ça de manière hardware, comment savoir si c'est le cas sur une carte CF quelconque ? même question pour les clé USB (j'en doute, sauf sur les carte haut de gamme peut-être)

si jamais cette protection est disponible en hardware, quel système de fichier utiliser ?

ext3 ne semble pas approprier à cause de la journalisation. ext2 ? quoi d'autre ?

l'utilisation de l'option noatime semble aussi intéressante.

le tmpfs sur la RAM est alouable dynamiquement.

pas de problème si il y a des modules à installer et noyaux à compiler. je compte d'ailleurs faire un noyau optimisé pour cette plateforme (plus tard !)

je compte utiliser debian, voir ubuntu-minimal pour commencer (je migrerai plus tard vers quelque chose de plus personnalisé)

je testerai aussi coreboot, vue que j'ai récup deux EPROM PLCC32 compatible avec celui-ci.

un PC avec software 100% libre

j'ajouterai peut-être un autre type de mémoire dans le fuur, sûrement à base de flash (clé USB de grosse capacité, autre CF, autre type de mémoire relativement lente)

c'est juste pour stocker des données genre musique et vidéo, les débit (bien que faibles) sont suffisant, je ne dépasserai pas la vidéo SD de toute manière avec ce CPU (bien que le contrôleur gère le 720P et même le 1080i)

si vous avez des avis, lien, idée n'hésitez pas

j'ai mis un mandriva 2008 complet sur un CF 12Go.
- j'ai mis ext2 bien sur.
- desactivé les log
- pas de swap
- 1Go RAM suffisent très bien (depuis un bon 6mois)
ça boot en 30sec. les applis sont très réactives

whatelse... \o_

salut,
 
merci pour les infos.
 
pas de SWAP, c'est sûr et certain (avec 512Mi de ram, je n'ai jamais utilisé mon swap, alors avec 1Go...)
 
ce que je veux c'est surtout que le système soit copier en RAM, tel que le fait puppy linux (je suis d'ailleurs en train de le tester sur virtualbox) et qu'il y ai le minimum d'écriture / lecture sur la CF, pour deux raisons : la première est que je ne veux pas user prématurément le(s) module(s) NAND (bien que le jfss2 ou une gestion hardware regle le problème), mais aussi pour augmenter significativement la réactivité du système (avec un système complet en RAM, les acces / transfère sont nettemnt plus rapide)

Jette un oeil au fonctionnement des live CD.
Ca répond à tes besoins pour :
- limiter les écritures sur la CF : les CD sont en read only...
- chargement du système en mémoire : c'est aussi ce qu'ils font
- minimiser la taille de la partition système : FS compressé (squasfs)
 
Quelques autres idées :
- reprendre la bonne idée de l'eeepc qui utilise une seconde partition montée en unionfs pour installer de nouveaux programmes et faire les mises à jour. La partition système reste intact et il n'y a qu'à formater cette seconde partition pour revenir à un système "tout neuf" sans avoir à tout réinstaller.
- regarder les paramètres de montages d'un disque USB : ils ne sont synchronisés qu'au démontage (peut être aussi quand le cache est plein). Ca te permettra de conserver un /home par exemple tout en limitant les écritures.

salut,
 
 
merci des infos  
 
pendant un moment j'ai tourné sur un liveUSB d'ubuntu (ma seule option à ce moment : pas de HDD, pas de lecteur) et j'en était satisfait.
 
la seconde partition en unionfs me semble très interressante :
 
systeme sur la CF, squashfs, copie en ram
deuxieme partition pour les prog et maj (unionfs)
 
c'est aussi ce qui est utilisé pour les liveCD je crois.
 
une question tout de même : comment vont s'appliquer les réglages ? la partition étant en lecture seule, comment les fichiers de configuration peuvent-il être modifié ?
 
 
sur un liveCD (ou liveUSB), le systeme est monté en mémoire, mais les programmes sont lus à partir du media.
 
est-il possible de faire en sorte que tout les programmes soient monté en mémoire (le systeme fonctionnerait alors même si la CF était retirée par la suite) ? du moins tout ceux dont je me sert quotidiennement (c'est à dire un espace disque d'environ 500Mo, un systeme complet de cette taille plus quelques logiciel me suffi largement sous virtualbox, ça sera aussi le cas sur une plateforme en dur), avec ceux utilisé plus rarement sur une autre partition accessible en lecture/ecriture ?
 
en somme je fait mon installation completement à la main, avec juste le necessaire (base debian + openbox + programmes importants), cette partition étant en lecture seule et copiée intégralement en mémoire, et sur une seconde partition les programmes moins courant, sur une partoche en lecture/ecriture.

Les fichiers sur la partition en RO ne sont pas modifiables sur cette partition... C'est bien pour ça qu'on dit qu'elle est RO.
En revanche, si un fichier de même nom est créé sur la seconde partition, c'est lui qui sera visible, la fichier d'origine sera "masqué".
Si tu supprimes le fichier sur la seconde partition, tu reviens au paramétrage d'origine.
 
Pour ce qui est de monter tous les programmes en mémoire au démarrage, il y a peut être une solution plus élégante mais tu dois pouvoir le faire en modifiant le script d'initialisation pour ajouter les étapes suivantes :
- créer une partition de 500 Mo en ram (ramfs?)
- copier le contenu de la partition système dans la ramfs
- monter la ramfs sur / en utilisant le principe d'unionfs

salut,
 
encore merci pour ton aide.
ramfs n'a pas de taille fixe il me semble (d'après wikipedia), ce qui est un point fort à mon sens. mais je ne sais pas comment l'exploiter concrètement.
 
pour ta solution, il y aurait donc :
 
une partition fixe (squashfs) avec le systeme de base + logiciels, une partition ramfs crée au démarage et une 2eme partition sur la CF avec un format classique (ext2 par exemple)
 

C'est une solution.
Cela dit la copie en ram risque d'augmenter consdérablement la durée de boot.

500Mo à copier en ram à partir de la CF.

vue les débit de la CF, ça sera forcément long.

la meilleur solution est d'utiliser la mise en veille prolongée.. (suspend to RAM).

un systeme linux stable n'a pas besoin de redémarrer

compte tenu de la plateforme employée, ce mode de mise en veille ne consommera qu'une broutille (je vais essayer de trouver de la mémoire basse tension, au profit de la consommation)

je vais faire des essais avec crunchbang (unbuntu + openbox, très leger, sauf en espace disque...).

il n'est disponible qu'en liveCD, mais je peux simplement le personnaliser pour virer tout ce qui ne me sert pas, voir changer le noyau par un noyau perso.

mais cela ne résoud malheuresement pas mon problème : le liveCD va charger une grande partie du systeme en mémoire, mais pas tout le contenu (heureusement...)

hors vue que je compte allèger le liveCD à fond, ça ne me pose pas de problème que tout soit copié en RAM.

j'ai trouvé deux options de boot interressantes :
 
 
toram
copy2ram
 
seulement tout les liens que j'ai trouvé sont en anglais, et bien que je n'ai pas trop de problème avec cette langue, je n'ai pas trouvé de détails concernant ces options.

Coucou,
 
J'ai justement en tête de vouloir installer une "bonne" distrib linux sur un portable compaq presario 2800 avec 1 GO de mémoire et 80GO de stockage.
 
Je m'étais un peu renseigné sur le chargement d'un OS en mémoire et ça m'a séduit.
 
Vous parlez de Compact Flash, je suis un peu dépassé, tous les pc n'acceptent pas ce genre de mémoire ?

Bon, j'me suis un peu renseigné, j'ai trouvé des lecteurs CP pouvant se brancher en PCMCIA via un adaptateur. Comme l'objectif c'est de créer un ramdisk et sachant que ce procédé utilise la mémoire vive, d'après-vous est-il possible de créer ce ramdisk à partir de la Compact Flash?
 
Si c'est possible, c'est plutôt un avantage car les CP ne sont pas volatiles contrairement à la mémoire vive...
 
Sinon est-ce que ces mémoires sont rapides et son-telles aptent à résister à l'écriture ?
 
Maintenant, si vous connaissez d'autre support de mémoire bien plus "avancés" que la Compact Flash, merci de m'aider là-dessus
 
 
 
Merci !

une netbsd ça serait pas dégeu sur ce genre de matos

Lol, oui, mais les questions que je me pose (ci-dessus) tu peux essayer de m'éclairer ?

salut,

la compact flash et parfaitement optionnelle, j'ai choisi ça pour d'autre raison, mais si tu a un disque dur dans ton portable ça fera largement l'affaire.

pour le moment je travail sur une distrib LFS, je verrai ensuite pour un ramdisk.

Oui, j'ai bien un disque dur dans mon portable mais je me demandé si le fait de créer un ramdisk sur une compact flash pouvait avoir des avantages notamment éviter de rebooter et de voir ces données envolées étant donné que la compact flash est une mémoire non volatile...?
 
Maintenant, comme le temps d'accès d'une compact flash est bien plus rapide qu'un disque dur standard, si j'installe un OS sur ce support, il serait bien plus réactif...?
 
L'inconvénient peut être c'est qu'en débit les compact flash sont pas plus avancées qu'un disque dur, que ce soit en lecture ou en écriture, quoi que les nouvelles compact flash à 300x font du 40Mo/sec!!  
 
Pour info, j'ai fait un benchmark sur mon dd portable IBM; il affiche un temps d'accès de 18.8Ms avec un taux de transfert moyen à 15Mo/sec alors que je le trouve bien suffisant et plutôt rapide.
 
Autre inconvénient, je crois qu'en écriture elles sont limitées, j'aimerai trouver des infos sur des systèmes de fichiers adequat pour éviter de faire travailler les CF en écriture, des idées ? (jffs2...ou ext2...? pour la lecture, aucune limite^^)

jffs2 c'est fait pour

Merci zecrazy. Bon, posons les questions précisément :
 
Créer un ramdisk sur une CF pourrait avoir l'avantage de sauvegarder automatiquement mes données notamment après un reboot et accélérer d'avantage le module mémoire ?  
 
En fait je vois les choses de cette façon:
 
en supposant vouloir installer OpenBSD, NetBSD ou FreeBSD, l'idée c'est de créer sur la CF l'OS avec le système de fichier Jffs2
 
Est-il possible, sur un même OS, de créer plusieurs partitions sur deux DD différents ?
 
Si c'est possible, alors j'expose l'architecture de mon esprit tordu ^^ :
 
Partitionnement sur la CF:
 
/ (Partition racine du système sur ramdisk en Jffs2...?)
 
/boot ( ext2...?)
 
/home (Là aucune idée du système de fichier...?)
 
Le reste du partitionnement sur un dd 5400TPM :
 
/usr (reiserfs...?)
 
/var (ext2...?)
 
/root (reiserfs...?)
 
 
Voilà en gros ce que j'aimerai faire, si vous pouviez, à chacun de mes points d'interrogations, m'apporter vos avis perso, ça m'aiderait beaucoup  

c'est possible, mais quel interet de mixer ainsi les FS ?
et puis avoir des bouts un peu partout, ça n'améliorera pas les perfs, et ça pas d'interet notable.
 
pour les BSD, je ne sais pas si le jffs2 est vraiment bien supporté et utilisé. Il est présent dans pkgsrc, mais je pense pas qu'il soit vraiment utilisé pour bsd.
 
A ce que j'ai lu à droite à gauche, tu peux incorporer un fs minimal dans le kernel.
j'ai trouvé un lien intéréssant sur un framework/toolchain pour ça:
 
http://code.google.com/p/bsd-appli [...] alkThrough

le disque dur aussi est une memoire non volatile, c'est donc du pareil au même.

le temps de réponse est nettement meilleur sur une CF (en dessous de la milli seconde), mais les débits sont faibles. les logiciels se lancent rapidement, sauf si ils sont gros. pour les debits, ils sont souvent très faible sur les CF. 40Mo/s, c'est de la théorie : en pratique c'est dur de dépasser 30Mo/s sans devoir débourser une fortune.

ça ne sert à rien, tout les contrôleurs flash recent intègrent ces fonctions. la durée de vie d'un CF dépasse celle d'un disque dur dans pas mal de cas.

malheureusement les performances de la mémoire RAM n'ont vraiment rien à voir avec celle d'un compact flash.

bien au contraire, cette partition peut être en lecture seul (pour peu que tu ne change pas de kernel toute les semaines)

pour le reste, je vais regarder ça plus attentivement mais pas maintenant

Merci oliv49 de m'apporter tes connaissances.
 
Quand tu dis que le disque dur aussi est non volatile et que c est du pareil au même, faut quand même admettre, qu'en dépit d'un faible taux de transfert que nous offre les CF, leur temps d'accès est bien plus performant que les DD, sans compter l'absence total de bruit, le peu de consommation, le poids.
 
Comme tu le dis, le temps de réponse est nettement meilleur sur une CF à défaut du débit qui lui n'est pas térible, c'est pour cette raison que j'aimerai pouvoir installer seulement la racine contenant l'OS, le /boot et /home, le reste pourrait se retrouver sur un DD standard notamment tout ce qui est journalistique comme /tmp, /var... Mais comme l'a fait remarqué "zecrazytux" je ne sais pas si avoir des partitions éparpillées de cette façon améliorerait les perfs...mais il y a un intérêt, celui de séparer les données changeantes et éviter à la CF de trop travailler en écriture.
 
j'ai repéré ce genre de CF :
 
http://www.ldlc.com/fiche/PB00064969.html
 
Si les contrôleurs flash recent intègrent une technologie leur permettant de se restreinde en écriture et que de ce fait, leur durée de vie dépasse celle d'un DD standard, voilà une bonne chose ^^
 
Ce qui reste confus encore, mais je crois avoir à peu près compris, c'est ce ramdisk sur la CF, quoi qu'il arrive, et ce quel que soit la mémoire utilisée, si je crée un ramdisk c'est la mémoire vive qui est utilisé et de ce fait, aucune sauvegarde automatique n'est envisagée si jamais le pc venait à rebooter ? Donc un ramdisk peut être utile à placer sur une CF pour créer une partition /boot, /tmp, /var...? bref, tout ce qui est journalier pour "décupler" à la fois le boot de l'OS et de vider les données changeantes ?
 
Maid admettons que je veuille installer un OS via un ramdisk sur une CF et que je personnalise un peu mon bureau, au reboot, ma personnalisation aura disparue pour revenir à celle du départ...?  
 
J'ai du mal là-dessus dsl.

c'est là qu'intervient ton montage /home, voir pousser à utiliser l'unionfs sur linux

Comment ça zecrazytux?

une ramdisk avec un fstab bien configuré pour que ton /home soit sur un FS monté en rw
 
et documente toi sur unionfs, c'est un peu plus poussé pour jouer avec différents fs en ro/rw

commence par essayer damm small linux, ça devrait bien tourner sur ton portable (bien que je ne soit pas fan du fonctionnement de cet OS... les modules additionnel j'aime pas ça, je prefere compiler à la main)

pour les debit des CF, j'ai fait un mini comparatif à partir de plusieurs test de différents sites :

sandisk ultra II : 7.6Mo/s en lecture, 5.4 en ecriture
sandisk extreme III : 16.7 en lecture, 12.3 en ecriture
sandisk extreme IV : 29.4 en lecture, 17.5 en ecriture
A-DATA speedy serie : 15.4 en lecture , 4 en ecriture
A-DATA turbo serie : 28 en lecture, 20 en ecriture
trenscend 266x : 16.7 en lecture, 12,5 en ecriture

personnellement c'est surtout la vitesse en lecture qui m'interresse, vue que je vais juste stocker le systeme dessus et que je ne risque pas de le changer tout le temps. tout mes fichiers sont sur le reseau, donc pas besoin de stockage interne.

la A-DATA speedy serie coute vraiment peu cher et offre des debit suffisant en lecture (honteux en ecriture par contre)

la turbo serie à un très bon rapport perf / prix.

 
C'est mon objectif également. Mis à part que mes fichiers ne seront pas sur un réseau mais un DD standard.
 
Pour les débits des CF, j'ai quand même trouvé une à 45Mo/sec (testé à 39Mo/sec) voir lien ci-dessus.
 
zecrazy, quand tu dis :
 
une ramdisk avec un fstab bien configuré pour que ton /home soit sur un FS monté en rw
 
et documente toi sur unionfs, c'est un peu plus poussé pour jouer avec différents fs en ro/rw
 
En fait habituellement je tourne sur XP, je suis pas du tout familiarisé avec linux... Ceci-dit je compte m'y mettre sérieusement pour pouvoir compiler mon propre OS.
 
Oliv49, en fait, d'après ce que j'ai compris, on a à peu près les mêmes objectifs...
 

c'est la vitesse réelle en lecture ? quesque ça donne en ecriture ?

l'idéal serait d'avoir un retour de commande hdparm -tTi sur cette CF.

exact, mis à part que tu utilise un disque dur, moi le reseau et/ou disque dur externe (ce qui revient plus ou moins au même)

le plus gros souci que j'ai, c'est que je n'arrive pas à definir quel dossier systeme va ou.

par exemple, le dossier /boot peut être en lecture seule sur la CF puisqu'il n'est utilisé qu'au démarage. le dossier /usr est le plus gros chez moi (et de loin, mais plus pour longtemps, LFS powered ), il doit donc rester en lecture / ecriture sur la CF. enfin les logs demandent des acces fréquents à la mémoire, mais on les perd à chaque redémarage si on copie ce dossier en RAM...

l'idéal serait d'avoir un script qui copie les modification apportée aux dossier de ce style lors de l'extinction. bien sûr en cas de coupure de courant, on perd toute les modifs...

si quelqun a déja réalisé ou travaillé sur ce genre de systeme, son aide ne serait pas de refus

par exemple, le dossier /boot peut être en lecture seule sur la CF puisqu'il n'est utilisé qu'au démarage. le dossier /usr est le plus gros chez moi (et de loin, mais plus pour longtemps, LFS powered ), il doit donc rester en lecture / ecriture sur la CF. enfin les logs demandent des acces fréquents à la mémoire, mais on les perd à chaque redémarage si on copie ce dossier en RAM...
 
l'idéal serait d'avoir un script qui copie les modification apportée aux dossier de ce style lors de l'extinction. bien sûr en cas de coupure de courant, on perd toute les modifs...
 
si quelqun a déja réalisé ou travaillé sur ce genre de systeme, son aide ne serait pas de refus
 
 
 
 
syslog-ng ? montage nfs ?

En écriture c'est la même chose, j'ai un pote qui l'a testé et il m'a dit qu'il atteignait les 38Mo/sec en écriture et 43Mo/sec en lecture!

De mon coté, j'compte pas utiliser l'écriture mais uniquement la lecture notamment pour la partition / et /boot, après peut être que j'installerai quelque logiciel tel que firefox, XMMS, Amarok, etc sur la CF (quoi que, admettons que je sois sur mon OS fraichement installé sur ma CF, si je fais du traitement de texte et que j'enregistre mes documents très peu encombrants sur cette partition, là je serai en mode écriture ?)

Mais c'est encore confus surtout pour l'organisation des dossiers systèmes (même souci qu'oliv49)

je comprends pas bien ton but pr0faz, si ce n'est geeker et paprendre des choses.
T'as pas de matos mini/micro, tu veux pas en faire un routeur, uns erveur quelconque...
 
tu cherches juste la perf ?

C'est ça zecrazy, je cherche uniquement les perfs, comme je sais que les temps d'accès des CF sont nettement plus rapides que les DD, je compte juste "jouïr" de cette qualité, sans compter l'absence totale de bruit, l'économie d'énergie et le poids aussi.

salut,
 
pour ma part j'utilise du matos relativement limité en puissance (geode LX800), je veux donc l'exploiter à son maximum (on commence par LFS, ensuite on verra pour le reste)
 
j'ai voulu essayer damm small linux, car il correspondait parfaitement à ce que je voulais en terme de "but" de distrib (surtout dsl-n), seulement je trouve la gestion des paquet vraiment peu interressant.... préfère encore me tourner vers la doc LFS.
 
d'ailleurs une chose me semble étonnante : lorsque j'ai testé DSL, celui-ci indiquait (dans le mode choisi) que tout le systeme était chargé en mémoire.
 
pourtant il m'a fallu 4 secondes pour lancer firefox (bon en temps normal c'est 10s, donc je ne me plein pas).
 
pourtant il n'y a rien à charger compte tenu du fait que tout est déja en mémoire ?
 

Dsl oliv49, j'connais pas la réponse
 
Je me documente pour adopter un système BSD.

Eeet oui et non... en fait, il decompresse les donnes live, mais je charge pas la memoire avec _tout_ les programmes... imagine ouvrir tous les programmes en meme temps, ca exploserai, et en plus ce ne serait pas viable techniquement. Donc il y a decompression, lorsque tu cliques sur ouvrir firefox par exemple... ce qui prend du temps-CPU. Avec un Geode LX800 en plus  

salut,

merci pour ta reponse.

si je comprend bien la racine (exepté quelques dossiers) est monté en RAM, et lors de l'ouverture d'un programme, le CPU doit decompresser les fichiers dans l'espace disponible de la ram ?

dans ce cas, pourquoi ne pas utiliser un fs non compressé ? quel systeme utiliser ? (ramdisk semble à proscrir) ramfs ? tmpfs ?

pour un systeme complet avec toute les appli que j'utilise au quotidienm me prendrais entre 150 et 250Mo. j'ai actuellement 512Mo de ram (28 sur mon PC fixe, là ou je compile LFS...), ce qui me laisse de la place pour le reste des programmes, 256Mo me suffisent emplement en temps normal.

je vais regarder les fs utilisé dans ces cas là.

edit :

http://fr.wikipedia.org/wiki/Ramfs

les programmes étant réellement utilisé en mémoire (et non pas dans une partition classique peu performante de taille fixe), sont-t-ils recopié pour l'utilisation ?

par exemple les librairies, si elles sont déja en mémoire pourquoi les recopier ?

le tmpfs semble donc une bonne alternative, avec un unionfs sur certain dossier ? (voir un script de sauvegarde ?)

je pense de plus en plus à integrer une batterie pour assurer l'alimentation de la mémoire ram.  la tension désirée là où il faut grace au pinout, avec peut-êre un trigger ou deux. malheureusement je ne sais pas combien consomme une mémoire vive de ce type, ce qui est un point important en cas de non utilisation prolongée.

est-ce que la carte mère ne va pas faire un reset de la mémoire ? grub ou un lanceur quelconque peut-il lancer un systeme qui n'a pas bouger (par exemple lors d'une coupure de courant), comme si il avait continuer de tourner ?

ça fait pas mal de question désolé

 
   
 
Tu sais ce que tu fais, là ?    
Parce que dans le genre bidouille hautement improbable, ça se pose là

c'est pour ça que je demande

ça ne semble pas impossible puisque des donnée peuvent être récupèrée d'une mémoire "à froid", juste après la coupure d'alimentation du module.

suffi-t-il d'apporter une alimentation constante du module pour assurer la sauvegarde des données contenu, ou d'autre manips sont necessaires ?

on s'écarte du sujet, mais je n'ai trouvé aucun post parlant de ça sur de nombreux forum

le gigabit i-ram utilise une batterie pour conserver les données en mémoire (dans ce cas là la mémoire fait réellement office de support de stockage)

Oliv49, d'après ce que j'comprends tu voudrais que tes données se sauvegardent, pourquoi n'utilises-tu pas un DD  pour tout ce qui est données et la journalisation tel que /tmp, /var... et une CF uniquement pour l'OS, voire le /boot (pour accélérer l'démarrage) ?
 
A moins que tu veuilles absolument utiliser un ramdisk avec une sauvegarde équivalente à celle d'un DD...?
 
Où je suis à coté de la plaque...
 

Au passage je dispose de deux routeurs sous debian lenny avec u / en readonly. Les répertoires nécessaires sont montés dans des tmpfs. Si ça interresse quelqu'un je peux vous filer quelques infos, n'hésitez pas

non non, le but c'est réellement d'utiliser la ram en temps que stockage principal (tel que l'i-ram).

suffi de faire des backup de temps à autres sur la CF et c'est bon

avec un module ram de 1Go ça peu le faire, perso ça me suffi largement pour un systeme.

pour le ramdisk on évitera, niveau perf c'est pas la joie.

ça serait un peu l'équivalent d'un suspend to ram.