Reprise du message précédent :
Pour FF, de mon coté, je n'ai utiliser le tmpfs que pour le répertoire du cache (sans sauvegarde ni restauration)? Quel intérêt(s) y a t'il à le faire pour tout le répertoire ? (surtout que ça oblige à faire une sauvegarde / restauration)

L'intérêt c'est surtout de stocker en ram la base SQLite qu'utilise FF3, c'est cette base qui est responsable du gros temps de chargement de FF lorsque le profil est sur un disque lent, ainsi que des nombreux accès disques au cours de l'utilisation.
Cette base stocke l'historique, la base anti-phishing, les bookmarks, ...

On le sent clairement lorsqu'on tape unmot clé pour la première fois de la session dans la barre d'adresse (Awesome Bar), ça lance directement une requête dans la base de données, sur le SSD de l'AAO ou sur un HDD un peu lent, ça peut être très long, là c'est quasi instantané.

J'avais ressenti peu de différences avec le cache en RAM, mais là, le profil complet, ça change tout  

Edit : je n'ai pas modifié les réglages par défaut de FF, donc le cache se retrouve également en RAM avec cette manip, vu qu'il est stocké dans le profil.

ça donne envie de tester... (j'ai pas de netbouc, mais l'astuce est valable partout !)

Et ça utilise peu de ram, en plus :
 

 
Yep. Les file descriptors déjà ouverts continuent cependant d'accéder aux données sur la partition en "arrière plan".

 
   
 
Intéressante précision  

Je ne comprends pas trop cette histoire de file descriptors... un exemple, SVP ?

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

donc si je comprends bien, un programme qui accèderait à ces données avant le montage du tmpfs continuerait à fonctionner normalement...
De quoi foutre un joli bazar dans certains cas, non ? (fichiers doublons...)
Enfin bref, on est HS là...

logiquement, le tmpfs est monté *bien* avant que mozilla-firefox ne soit lancé .

C'est pour ça que je disais que du coup c'était HS...

Je confirme l'augmentation de réactivité flagrante avec l'utilisation du scheduler deadline. noop était pire que celui par défaut!

M300A : quel est ton netbook ?

Pour Ubuntu/Linux4one j'ai ajouté pour le démarrage dans /etc/init.d/rc.local mais je ne vois pas où mettre la commande de sauvegarde à l'arrêt...

Par contre le gain de performances est flagrant, merci  !!

edit : Acer Aspire one A110...

 
EEEPC 901 Linux, donc Atom, 2Go de RAM (upgrade maison), SSD 4Go MLC, SSD 16Go SLC

Sous Debian testing, kernel 2.6.28.

tu crées un /etc/rc.local-stop par exemple et tu l'ajoutes en script de fin .

Correction :

Dans le /etc/rc.local.shutdown :

Est plus approprié : sans l'option --delete, les fichiers obsolètes et qui ne sont plus présents en RAM continuent d'être stockés sur le SSD, et sont copiés quand même en ram au boot.
Là on a une vraie synchro, avec suppression si nécessaire.

Évidemment on pourrait mettre la même chose dans le rc.local (pour le boot), mais c'est inutile, le ramdisk étant toujours vide au boot.

J'avais de moi-même rajouté l'option --delete...  
Merci tout de même d'avoir mis tout ça par écrit !

merci pour la correction, ça explique un bug sur la gestion de session de firefox

Je galère un peu :  
 

 
C'est comme ça qu'il faut faire ???
 

A priori, tu utilises Ubuntu, je posterais donc la question plutôt (ou aussi) sur le forum de ta distribution.

Juste à titre indicatif, ça donne quoi comme performances avec hdparm vos SDD ?
J'avais indiqué, y a quelque temps déjà, les résultats sur un OCZ Solid Series SATA II 2.5" SSD.

J'ai ça sur mon Aspire One et son SSD Samsung de 8Go :
 

Depuis aujourd'hui j'utilise KMS sur mon Aspire One    
 
http://tuxce.blogspot.com/2009/03/ [...] linux.html
 
Ça fonctionne très bien, mais ça oblige à utiliser UXA, avec lequel j'ai moins de perfs que EXA.
Pleine résolution dans les ttys, switch immédiat X->tty, très rapide dans le sens inverse, très sympa

c'est la même procédure avec Ubuntu Jaunty + un noyau 2.6.29 ?

http://linuxfr.org/~octane/28089.html
un petit lien sur firefox qui se rapproche de la proposition précédente d'utiliser  le tmpfs.
Le script est lui par contre un peu différent

intéressant , même hors notebook d'ailleurs.
En fait, ce qui manque pour cet usage précis, c'est un FS qui se monte en union en tmpfs et recopie sur le FS sous-jacent de temps à autre. Personne connait ça ?

avec un cron peut-être ?

justement, je voudrais pas une solution avec un cron mais directement avec le FS (une synchro au démontage m'irait très bien aussi).
Un peu commun un FS union : on expose le FS sous-jacent mais on modifie sur un autre, sauf qu'en plus là, on recopierait sur l'initial de façon différée.

 
Intéressant, mais c'est vraiment une solution dédiée "Firefox portable" je pense : dans le cas d'un poste stable avec un Firefox "statique" (un desktop, ou même un netbook), la solution du tmpfs créé au boot a l'avantage de provoquer moins de lourdeur au démarrage de FF.
(sachant qu'un crash complet de la machine ne perd de toutes façons que la session en cours)
Sur l'Acer Aspire One, j'imagine même pas la lenteur du lancement et de la fermeture de FF avec ce script.
 
Et avec beaucoup de ram, on peut se permettre de garder le cache (ce qui ralentirait pas mal son script je pense, un tar complet VS un rsync beaucoup plus rapide).
 
Sur mon desktop avec 4Go de ram, j'ai laissé le cache offline (maxi 512Mo), qui réside donc complètement en ram. (après c'est un choix suivant les besoins que l'on a en mémoire : FF est l'appli que j'utilise 100% du temps et pour 80% de l'utilisation de mon desktop, ça ne me dérange donc pas d'y consacrer tant de ram)
Mais on s'éloigne un peu du sujet.  

Intéressant ce topic
 
Mettre ff en ram est intéressant, mais je trouve un peu dommage de devoir fixer un dossier d'un utilisateur en dur. N'y a t-il pas moyen de mettre un $user/.mozilla en ram à la place d'une donnée en dur ?
 
J'ai testé le week end dernier diverses solutions (flashybrid, unionfs, aufs) et je suis comme Mjules à propos de la sauvegarde de données. C'est dommage de ne pas avoir une fonction interne au FS pour le prendre en charge tout seul.

Voici qq idées, dont je ne maitrise aucunement l'aspect technique (mais je serais intéressé pour avoir la solution) :
 
1. multi-user :avec un script et une boucle for, ça doit être possible.
 
2. filesystem : et un système raid (RAM + HDD) sur ce(s) répertoire(s) ? éventuellement un hard-link ?

Ma petite contrib alors:
Avoir un netbook (ou un SSD, CF, ou système sur de la mémoire flash), c'est bien, mais autant ne pas y mettre des trucs inutiles, comme les paquets téléchargés par sa distrib.
Donc, en gros il suffit de mettre le dossier où sont téléchargés ces paquets (et les paquets partiels) en tmpfs.
/etc/fstab (pour debian/*buntu):

Et le script qui va créer le dossier partial au boot (chose bizarre de tmpfs, pas moyen de créer un dossier en ram inclu dans un autre dossier en ram ):

Suivi d'un chmod +x sur le script et d'un update-rc.d aux bons runlevels.

Et c'est bien utile de manger un peu de ram quand le disque système est petit

J'ai fait un peu pareil sous Arch : mon /tmp est monté en tmpfs, donc j'ai bêtement configuré Yaourt pour stocker le cache des paquets dans /tmp/yaourt
Comme ça c'est vidé à chaque boot, et le DL des paquets ne rame plus autant qu'avant avec ce SSD anémique.

 
http://www.mjmwired.net/kernel/Doc [...] t4.txt#313

[:ceci est un ]
Heureux possesseur d'un 901b-16Go-Turbodiesel

+1  

que je viens d'ailleurs d'upgrader avec une minipciexpress Atheros qui claque

Je viens de repasser sur Debian pour mon portable (une Lenny, j'ai besoin d'un système rock stable sur cette machine), et voulant profiter de l'astuce du .mozilla en tmpfs, j'ai fait plus propre que sous Arch, avec un script d'init.
 
Rien de sensationnel, mais si ça peut servir ...
 

Il marche bien ce script ? J'ai tenté d'en faire un light, mais il manquais un header spécifique pour le "reconnaitre" comme un vrai script dans init.d