Est ce qu'il y a moyen avec linux d'avoir un fs en mémoire ?
J'explique
 
l'idée serait par exemple de remonter / de façon à ce qu'il soit accédé directement depuis la ram pour la lecture, et que les écritures soient transférées sur le disque
 
une sorte de cache en ram
je me disais qu'avec les squashfs ou unionfs utilisés sur les livecds il devrait y avoir moyen de faire ce genre de délire, ou que quelqu'un aurait déjà éssayé

Monter / en tmpfs non? Avec un rsync à l'extinction?
 
Je sais pas du tout si c'est jouable ou comment. C'est clair que ça pourrait être sympa.

En fait une autre idée me venait
je pense à une solution possible avec mdam en faisant un raid 1 entre une partition et un ramdisk  
 
a chaque démarage mdadm reconstruirait le ramdisk en tache de fond, et par la suite à priori mdadm devrait tenter d'accéder en lecture au périph le plus disponible qui devrait être le ramdisk (ou si il y a moyen de définir une priorité)
les écritures se feront comme d'hab sur les deux disques à la fois
 
à priori ça c'est quasi sur que ça marche
mon / fait 12G mais par contre j'ai pas 16G de ram
 
évidement normalement le cache disque de linux est censé faire ça pour les données déjà lues

 ACARD 9010 FTW  
certes tres cher mais insurpassable niveau perf, t’affranchis des problèmes de raid 1 boiteux et se cogne de l'os utilisé

 
non seulement c'est cher mais en plus ça retire tout le fun

trouve un ramdrive gigabyte et fait ton montage raid alors

/ sur un SSD de taille raisonnable (et donc abordable), /home sur un gros disque et pis voilà.

les perfs soint moins bonnes également puisqu'on retombe sur des vraies I/O par le contrôleur SATA, limitées à 300Mo/s et à je ne sais quelle latence, faible mais plus importante que en RAM.
 
le truc ridicule en mdadm, ça peut se tester pour un point de montage autre que /, avec un ramdisk de 256Mo s'il faut..

pas de swap, / sur disque dur, /var sur ssd, /home sur ssd , avec un /data de 2To à 4To.

Pourquoi avoir mis le / sur DD?

pour gagner de la place
l'idée est que les trucs qui ne bougent jamais, /etc, /bin, /usr etc. avec en principe aucune écriture, sauf installation ou upgrade, ça peut aller sur disque dur.

pleins de trucs là-dedans sont chargés en quelques secondes au boot et restent dans la ram.
les démons sont censés écrire dans /var, les programmes dans /home ou peut-être /var, et le /home sur ssd permet le chargement super rapide de la session utilisateur, des fichiers à la con dans le .mozilla etc.

c'est un peu académique tout ça, néanmoins imaginez plusieurs OS, peut-être des VM qui se partageraient un seul SSD faut économiser la place.
ou ce que j'aimerais bien voir personnellement, un SSD rapide de 8 ou 16Go à 15 ou 20 euros . bon, ça c'est peut-être avec une future techno qui remplacerait la flash..

de tte façon j'ai un vieux hdd 7200 tours (?) de 20Go comme / et home, ça me va encore, tant qu'on évite gnome3 (d'ailleurs mon système est une espèce de mix de gnome3 et lxde, bon, ça marche encore)
KDE je n'essaie même pas.

je n'ai pas d'argent à mettre dans nouvelle CM + 4Go ddr3 + ssd 60Go, ou alors ça part dans autre chose (comme dernièrement une carte son, et prochainement un netbook arm avec 3G)

Je vais bientôt pourvoir tester le tout sur un ssd de mon côté ça devrait me changer la vie.

 
Lol et pourquoi pas juste avec mdadm ?

Pourquoi autre que / ?
En dehors du fait que j ai pas assez de ram actuellement il y a pas de raison.
Ca reviendrait a booter degradé et a ajouter un ramdisk en spare drive dand rclocal par exemple
Le boot serait bien sur pas acceleré vu qu il faudrait attendre la synchro pour profiter de la lecture sur le ramdisk

je veux dire juste pour tester.
après on doit pouvoir faire tout autrement et de plein de façons, là une idée qui me vient est de tout copier dans le ramdisk et se chrooter dans le ramdisk?

le chroot sur un ramdisk ça se fait
nottament avec pbuilder qui permet de compiler des paquets à partir d'un environnement clean, qu'il dézippe à chaque fois
 

Pas besoin d'avoir 16 Go de RAM pour tester, voir installer une distrib :
 

Bon après je n'ai que 4 Go de RAM.

Vous voulez pas faire un topic bidouille dédié ?

c'est intéressant parce qu'on peut le faire avec debian. ou linux mint ubuntu.

je viens de commander une carte SD 8Go à 8 euros, classe 10, ça pourra toujours servir mais d'abord je compte installer un OS dessus, en ext2.
d'ailleurs c'est assez grand pour un / au final. dont le /home s'il ne sert qu'à contenir .mozilla, .config etc.

suffisant pour mon X2 avec 2Go de ram (j'aurais 4 ou 8Go de ram, mais ça demande des sous que j'ai préféré mettre dans la carte son)

1. donc ça ne concerne pas Debian particulièrement => topic dédié
2. non ça n'est pas intéressant
3. Regardez plutôt du coté de flashcache que de mdadm ( https://wiki.archlinux.org/index.php/Flashcache / https://github.com/facebook/flashcache )

EDIT: En fait si, ça peut m'intéresser le flashcache. Mais je pense quand même qu'un topic dédié est plus adapté

Rien que pour le trouver à prix pas trop abusé c'est fun (même sur la bay il n'est pas rare d'en voir à 2x le prix initial)

C'est dans le cadre de la question, pourquoi ressortir un autre topic ?
 
Pour le reste, par rapport à la question initiale, mettre carrément / en RAM je trouve cela foireux pour plus d'un titre :
- déjà il faudra gérer le montage propre (via rc.local ?)
- faire un pseudo-RAID ou un rsync dans le sens RAM -> HDD toutes les 5 secondes (voire moins si on travaille beaucoup) de manière à ce qu'en cas de coupure inopiné il n'y ait pas de perte (oui, une alim de PC peut tomber en rade subitement, même un gros modèle de marque )
- gérer l'extinction (via rc.local.shutdown ?)
 
Mettre /tmp, /var/tmp, /var/lock, déplacer le dossier de cache de Firefox sur un tmps (taper about:config puis rediriger ce cache vers votre dossier tmpfs en modifiant la ligne browser.cache.disk.parent_directory) etc... pourquoi pas, mais pas la racine  
En "solution" on peut donc passer par tmpfs, et ajouter dans son fstab :

Là je n'accorde qu'une faible place, mais bon 4Go de RAM, 2 d'utilisés (remplacer 512M pour 512Mo, par 1g pour 1Go, 2g pour 2Go,...)
C'est valable "tel quel" sur Ubuntu et Debian.
Sur Gentoo, c'est à adapter mais cela reprend les mêmes bases.

Ce post est issu de la discussion initiale sur le topic Debian

Oui, mais c'est en application générale, sans support d'une distrib en particulier.

C'est pour ça que je demandais alors de faire un topic dédié

Un topic dédié à la question sur Debian ? Tu ne compliquerais pas un poil les choses ou tu travailles dans l'administration et il te faut le formulaire 17-123a ?

T'as l'air d'être intelligent, mais de ne pas percuter bien vite  
 
Les 20 premiers posts (en gros), ont été fait sur le topic Debian.
Comme justement c'était une question généraliste, j'ai proposé que ce soit fait dans un topic à part.
Un modo est alors passé par là, a créé le topic, et a déplacé les posts du topic Debian vers celui-ci.
Donc mon post était dans le contexte (tu comprends la notion de contexte ?   ) du topic Debian.
 
C'est plus clair ou tu as besoin d'un schéma ?

Ah, autant pour moi.
 
Enfin bon, que cela soit sur Debian ou autre, tmpfs est supporté par le noyau 2.6+ donc osef.

Ben oui, on s'en fout, c'est que je dis depuis le début de la discussion
 
Et je persiste à dire que la piste à suivre c'est flashcache

Oui, mais non

Rien que parce que c'est écrit par fesse-bouque, j'éviterais.

Philosophie Debian quoi  
Tu veux une couche en plus ? Le contributeur sur le wiki d'Arch (même adresse que précédemment) a "lu" que flashcache ne fonctionne que moyennement sur les machines 32bits. Ce qui exclue d'office tous les vieilles bécanes à base de Pentium 4/Athlon XP et prédécesseurs.
 

Rien à voir avec la Philosophie Debian, c'est du GPLv2.
Le 32 bits, d'après le github, c'est résolu (bon, depuis 4 jours... ), mais qui utilise encore du 32 bits et cherche à utiliser ce type de techno sur un ancêtre ?
 
Sinon y a bcache, dans le même style : http://bcache.evilpiepirate.org
Mais difficile de savoir où en est le projet, si il est toujours vivant, le nombre de contributeur...

Toi, tu ne fréquentes pas les brocantes et les utilisateurs de vieilles techno@vraiment pas cher (genre du Xeon/Pentium 4/etc...) qui veulent justement faire accélérer leur bouzin ou qui sont utilisé en serveur@home, sans investir dans du matos récent

Non