vu le prix de la ram actuellement (35/36€ les 2Go de DDR2), et celui des SSD de bonne qualité (cher !), je me suis dit : pourquoi ne pas utiliser la ram comme un disque dur pour accélérer mon PC ?
Cette solution a été testée sur un eeePC 701, avec 2Go de RAM. 1Go de RAM a été dédié pour les fichiers système en RAM, il faut donc soit avoir un système light qui fait moins de 1Go (trop tard, je viens de tester KDE 4.1, je suis passé de 1Go à 1,5Go :p [et je n'ai pas tout installé]), soit ne charger que certains dossiers ou sous-dossiers.
Pour ma part j'ai choisi : /bin /sbin /lib /usr /var => 900Mo (oui, j'ai une Debian light :p)
(on peut utiliser des sous-dossiers sans problème)
Voici mon petit script pour initialiser les "ramdisk" et synchroniser les données entre la ram et le disque dur.
Le principe est simple :
- creation d'un tmpfs de 1000Mio
- copie de chaque dossier dans ce tmpfs
- montage de chaque dossier du tmpfs par dessus les originaux
- remount de / dans un dossier à part pour pouvoir synchroniser les modifications
Fichier : /etc/init.d/toram
#!/bin/bash
ROOTDEST=/mnt/root
DEST=/mnt/tmpfs
FOLDERS="/bin /sbin /lib /usr /var"
case "$1" in
start)
if [ -n "`df |grep /mnt/tmpfs`" ]; then
echo 'Déjà chargé.'
else
mount --bind / $ROOTDEST
mount -t tmpfs none $DEST -o size=1000m
for folder in `echo $FOLDERS` ; do
mkdir -p $DEST$folder
rsync -aru $folder/ $DEST$folder
mount --bind $DEST$folder $folder
done
fi
;;
sync)
for folder in `echo $FOLDERS` ; do
echo "Syncing folder : $folder"
rsync -aru $folder/ $ROOTDEST$folder
done
;;
*)
echo "Usage: /etc/init.d/toram {start|stop|sync}"
exit 1
esac
exit 0
Pour être sûr que les applications utilisent les nouveaux dossiers montés, il faut les monter le + tôt possible au démarrage de la machine.
Pour mes tests, je passe en "init 1" et je lance le script "/etc/init.d/toram start".
Cela prend 1m30s pour 1Go de données, sur ce SSD avec des débits faibles.
Pour éviter d'avoir un temps de boot aussi long à chaque fois, il vaut mieux utiliser la mise en veille :p
Pour synchroniser les données, il suffit d'un "/etc/init.d/toram sync".
La fonction stop n'a pas été écrite. Voici la technique manuelle :
#init 1
#/etc/init.d/toram sync
#umount "de chaque dossier" ou reboot (umount -l, pour forcer le démontage)
Arès qq jours de tests, il s'avère que sur cette machine, on ne gagne rien de visible, pour les raisons suivantes :
- le SSD, bien que lent en débit, a un temps d'accès très faible (
- le CPU est à la traîne pour les calculs : c'est lui qui limite clairement les performances de l'ensemble.
J'ai aussi testé en mettant mon profile firefox en RAM (/home/user/.mozilla), et je n'ai pas vu de différence notable non plu !
Ma conclusion serait que sur un PC avec HDD mécanique le gain serait certainement visible :
- le temps du 1er chargement en RAM serait bien réduit (75-90Mo/s pour un disque récent contre 20-25 pour le SSD du eeePC 701)
- la différence de temps d'accès entre le disque dur et la RAM serait vraiment visible (on le voit déjà avec un SSD, le temps de boot de linux est + court)
Bref, n'hésitez pas à donner votre avis sur l'utilité d'une telle chose, à tester, en particulier sur une config complète qui nécessiterait environ 4Go de RAM dédiée pour ce système.
# À étendre.
Posté par Ph Husson (site web personnel) . Évalué à 2.
On fait un 1° boot qui analyse les fichiers accédés pour un boot normal, on fait un gros tar.gz/bz2/lzma suivant le CPU des fichiers accédés (sur un systeme normal doit y avoir moins de 1% des fichiers qui sont accédés....)
Et après aux boots suivants on joue avec unionfs pour que les écritures soient en RAM (au démarrage de KDE dans /home y a énormement d'écritures que je qualifierais d'inutiles), ainsi que la plupart des lectures.
En ésperant que le gros tar.gz soit continu comme ca on "perd" le probleme du temps de latence du disque dur, contrairement à ton script.
[^] # Re: À étendre.
Posté par khalahan . Évalué à 3.
- minimiser les écritures sur le disque dur (une flash card ou autre),
- un liveCD avec l'image du CD en lecture seule et une autre image en écriture pour mémoriser les modifications du liveCD.
La technique dont tu parles sert uniquement à accélérer le temps de boot si j'ai bien compris ? (est-ce la technique utilisée par je ne sais plu quel liveCD pour booter + vite ?)
Ce que je cherche à faire c'est accélérer le lancement de toutes les applications en contre partie d'un chargement initial long. Sur mon eeePC ça n'a rien changé malheureusement et mon PC fixe n'est pas assez de RAM (760Mio).
Si cette astuce n'a aucun effet sur un PC avec un disque dur mécanique, cela signifie que la lenteur relative d'un disque dur n'a que très peu d'impact sur le chargement d'une applications (mais pas forcement au boot où plein de petites applis sont lancées).
ps : sur un PC capable d'exécuter 1 ou plusieurs milliards d'opérations par seconde, ça me fait chier d'attendre plusieurs secondes pour lancer la calculatrice gnome...
# hum
Posté par M . Évalué à 10.
[^] # Re: hum
Posté par dinomasque . Évalué à 5.
BeOS le faisait il y a 20 ans !
[^] # Re: hum
Posté par ribwund . Évalué à 6.
[^] # Re: hum
Posté par Kerro . Évalué à 2.
Une exception serait d'avoir un besoin d'écriture intensive qui ne dépasse pas 1 ou 2 Go. On pourrait dans ce cas mettre un tmpfs en shm par exemple. Qui a besoin d'écrire intensivement et régulièrement sur seulement 1 ou 2 Go ?
[^] # Re: hum
Posté par paipai62 . Évalué à 1.
Oui! Mais avec les risques de perte de donnée en cas de coupure de courant.
Application scientifique? Que tout le monde utilise!
[^] # Re: hum
Posté par Greg (site web personnel) . Évalué à 2.
Une question qui trainait dans mon esprit cependant: comment fait-on pour vider le cache buffer ?
[^] # Re: hum
Posté par Matthieu . Évalué à 8.
[^] # Re: hum
Posté par Greg (site web personnel) . Évalué à 1.
[^] # Re: hum
Posté par PLuG . Évalué à 2.
Sur les redhat il y a des scripts (readahead) qui se chargent de monter en cache ram les binaires les plus utilisés a un moment ou le disque n'est pas trop sollicité ce qui d'après eux accélère un peu le boot. Pour les monter en cache ils ne font que accéder a ces binaires puisque le noyau gère de lui même le cache....
bref a mon sens tout cela est inutile et compliqué (synchro ram-> disque ? le /var en ram c'est dommage si on veut consulter les logs ...)
[^] # Re: hum
Posté par dinomasque . Évalué à 8.
Mais c'était de la science fiction, pour ça il aurait fallu au moins ... 24Mo de RAM !
BeOS le faisait il y a 20 ans !
[^] # FOUTAISES !!!!
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: hum
Posté par octane . Évalué à 1.
J'avais réfléchi à la manière d'optimiser le premier chargement.
Ceci repose sur le fait que les disques actuels sont très rapides xxxMo/s en lecture, mais qu'un programme comme firefox peut mettre une dizaine de secondes à se lancer.
La répnse provient du fait que firefox est éclaté en xxx fichiers, xxx libs partagées, etc.. Donc le disque lit effectivement très vite un fichier (petit) puis perd beaucoup de temps pour replacer la tête de lecture sur un second fichier, etc.. Pour firefox, ca se voit un peu, pour KDE et/ou gnome, ça fait une myriade de fichiers de conf.
Et j'avais commencé à chercher à optimiser un programme comme firefox comme un unique gros fichier qui se charge en RAM, puis qui démarre. J'avais regardé du côté de e2statifier, ou d'un mécanisme de CRAMfs.
On a xx Mo à charger en RAM, le disque booste, tout est en RAM, puis les accès ensuite sont immédiats.
En conclusion, je n'ai vraiment rien eu de transcendant avec mes premiers tests et j'avais finalement laissé tomber l'idée.
[^] # Re: hum
Posté par Ph Husson (site web personnel) . Évalué à 2.
En gros 2 secondes dans les deux cas pour un démarrage "à chaud".
Bon après ca peut aider d'avoir un gros cramfs/tgz pour un démarrage à froid, mais ca bouffe de la RAM pour rien. L'idéal ca serait pouvoir d'initialiser le cache linux soit meme.
[^] # Re: hum
Posté par niclone (site web personnel) . Évalué à 4.
Tu peux..
Exemple :
Première étape, tu crée une liste de tout les fichier que firefox va ouvrir:
strace -f -e trace=open firefox 2>&1 | grep -v ENOENT | grep ' open("' | sed 's/^[^"]*"//' | sed 's/".*$//' | grep -v '^/dev/' | grep -v '^/tmp/' | sort | uniq > firefox-files.txt
Deuxième étape, après le boot par exemple, tu fais en sorte que le système mette en cache tout ces fichiers :
for f in $(<firefox-files.txt); do [ -f "$f" ] && cat $f > /dev/null; done
et voila.
[^] # Re: hum
Posté par ribwund . Évalué à 2.
[^] # Re: hum
Posté par Ph Husson (site web personnel) . Évalué à 3.
[^] # Re: hum
Posté par niclone (site web personnel) . Évalué à 1.
[^] # Re: hum
Posté par niclone (site web personnel) . Évalué à 2.
étape intermédiaire :
ls -id $(<firefox-files.txt) | sort -n | sed 's/[0-9 ]* //' > firefox-files-sorted-by-inode.txt
[^] # Re: hum
Posté par Ph Husson (site web personnel) . Évalué à 2.
Quand je dis de pouvoir initialiser le cache, c'est d'avoir un gros fichier, non fragmenté, donc en un seul morceau sur le disque qu'on pourra lire à 80Mo/s en fonction du disque dur.
Alors que ton for, bah il fait toujours perdre les têtes au disque dur, donc on ne fait que déplacer le temps de latence au boot au lieu du lancement de firefox.
[^] # Re: hum
Posté par niclone (site web personnel) . Évalué à 1.
il n'y a juste qu'a prendre les partitions de khalahan, et de faire au boot le plus tot possible:
dd if=/dev/partoche of=/dev/null bs=4M
[^] # Re: hum
Posté par nicoastro . Évalué à 2.
[^] # Preload / Readahead
Posté par _alex . Évalué à 3.
preload is an adaptive readahead daemon. It monitors applications that users run, and by analyzing this data, predicts what applications users might run, and fetches those binaries and their dependencies into memory for faster startup times.
Et il y a Readahead ( http://packages.ubuntu.com/fr/gutsy/readahead ) :
It allows the user to specify a set of files to be read into the page cache to accelerate first time loading of programs, typically during the boot sequence.
Par contre j'ai pas de stats précises sur l'amélioration ou non.
[^] # Re: Preload / Readahead
Posté par khalahan . Évalué à 1.
Je crois que ces 2 logiciels répondent en effet aux différents besoins de manière beaucoup + optimisée (pour le boot: readahead, pour le lancement des applis courantes : preload).
Il me reste maintenant à chercher les causes du temps de lancement affreusement long d'un simple programme par rapport à la puissance d'un PC. Linux aurait-il pris de l'embonpoint ces dernières années ? Les devs ont-ils tous des Dual Core ? :p
Peut-être un prochain journal.
[^] # Re: Preload / Readahead
Posté par lom (site web personnel) . Évalué à 1.
Sur un ordi recent (35s pour booter debian jusqu'au prompt), installer readahead me fait tomber le temps de boot a 30s (apres le premier boot ou il analyse tout, ce qui est tres long: 2minutes si je me souviens bien).
Je n'ai pas encore essaye preload, par contre, je vais tenter ca.
# Ssd supporte un nombre d ecriture limitee?
Posté par syj . Évalué à 1.
je te recommande donc de mettre en place ton système avec un fs adapté pour reduire au maximum les reecriture au meme endroit.
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par syj . Évalué à 1.
http://fr.wikipedia.org/wiki/Solid_State_Drive
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par Hank Lords . Évalué à 8.
Nombre de cycles d’écriture limité à 100 000-300 000 (gênant pour les fichiers de journal (logs) ou les fichiers temporaires). Néanmoins, des progrès ont été réalisés dans ce domaine, puisque des algorithmes de wear levelling (étalement de l'usure) chargés de répartir les écritures de manière uniforme sur l'ensemble de la mémoire flash sont intégrés aux contrôleurs des SSD. Ces techniques permettent d'allonger de manière importante la durée de vie de ces supports, et cela est d'autant plus vrai que la capacité des puces augmente (l'usure est alors mieux répartie).
Donc les algos de répartition d'écritures sont dans le controlleur et il n'y a pas besoin de fs particuliers pour avoir une durée de vie correcte sur un ssd.
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par syj . Évalué à 1.
En moins d'un an , j'ai eu 3 ou 4 utilisateurs d'en ma boite qui ont perdu les rapports sur lequel il travaillait car ils l'éditaient directement sur la clé et d'un coup un secteur defectueux bien placé dans la FAT et tout dégage.
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par ribwund . Évalué à 1.
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par Guillaume Knispel . Évalué à 4.
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par M . Évalué à 3.
Si c'est meme de la flash NAND.
y'a pas de wear-leveling hardware.
Bien sur que si. Apres les algos venant des clefs pas très cher ne sont pas forcement tres efficace...
Mais c'est pareil sur les disque ssd (ou sd-card).
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par Olivier Grisel (site web personnel) . Évalué à 0.
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par fcartegnie . Évalué à 2.
Tu vas rien retrouver du tout.
Photorec reconstitue les fichiers ou les systemes de fichiers d'après les informations qu'il trouve. Si les données recherchées sont dans un secteur endommagé (un "trou" physique), ça ne servira à rien.
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par Olivier Grisel (site web personnel) . Évalué à 4.
Peut etre que le bloc foireux n'etait pas critique pour openoffice et que ce dernier etait suffisamment tolerant pour s'en sortir et qu'on a eut beaucoup de chance mais ca a vraiment marché a 2 reprises.
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par M . Évalué à 3.
Faut arrêter de dire n'importe quoi.
Même s'il y a des algos de répartition d'écritures, un fs qui récrit plusieurs secteurs à chaque opération usera beaucoup plus vite la flash que celui qui récrit le strict minimun.
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Si je prend ma carte mémoire d'appareil photo, que je regarde le nombre de photos qui ont été écrites dessus, que je multiplie par le poid moyen d'une photo en mo, que je divise par la capacité de la carte, j'ai au moins réécrit la TOTALITÉ de la flash près de 100 fois.
Mais peut être que faire du je sature/je vide/je recommence c'est moins violent pour la flash que d'avoir en permanence les mêmes fichiers sur la clé pendant longtemps, et donc ne réécrire toujours que dans l'espace restant (et restreint), soit toujours le même (cas d'utilisation typique d'une clé usb).
Si ma carte mémoire commence à montrer des signes de faiblesse, elle se montre tout de même plus costaud que toutes les clé usb que je vois passer.
L'emploi typique d'un disque dur : j'ai des fichiers qui ne bougent jamais (archives, photos, musique, films...) ou peu (logiciels installés) ça ne doit pas être bon pour la flash : ça signifie qu'on réécrit toujours au même endroit le reste. Et plus le disque SSD est plein, moins l'espace disponible est grand, et plus on fusille la flash, à l'endroit où justement on en a besoin.
D'ailleurs, puisque Murphy est toujours avec nous, ce sont forcément les fichiers qu'on modifie très souvent qui sont les plus important. Ceux qu'on ajoute, ceux qu'on modifie, ceux qui n'ont que quelque jours, ceux qui sont utiles maintenant, pour tout-à-l'heure. Ce sont aussi ceux qui par définition n'ont pas de garantie.
Le fichier archivé en flash : il dors, il a ses secteurs bien propre et qui sont même encore neuf, ils n'ont jamais servi à d'autre que ce fichier.
Le fichier de travail, lui, c'est celui qui se tappe tout les secteurs usés que y a que le train qu'est pas passé dessus. C'est ce même fichier, le-plus-important-de-tous qui prendra les frais d'un secteur troué.
Et le fait que ce soient les fichiers les plus souvent modifiés qui prennent le plus cher, les algos de répartition ne peuvent que le ralentir, mais c'est une réalité intrinsèque à la technologie flash. Ce sera toujours "le document que j'écrivais" qui va sauter, c'est presque une lapalissade.
Mon disque-pas-flash actuel fait 120go, j'arrive à maintenir 3go de libre sur chacune de mes partitions /home et / histoire d'avoir de la marge de manoeuvre suffisante en cas de besoin de place d'un coup (décompression d'une vidéo, grosse mise-à-jour, préparation d'une image pour Qemu, compilation d'OOo -- ah non là il faudrait 3 fois plus --). depuis plusieurs années je réécrit constamment sur ces mêmes 2*3go, avec de la flash j'aurai un disque net sur 114go, et tout ruiné sur les 2*3go restant, là où justement je travaille.
Avec de la flash j'aurai planté depuis longtemps, malgré 95% de neuf parcequ'occupé par des fichiers dormants.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par beagf (site web personnel) . Évalué à 7.
Les bons algos de wear-leveling sont capable de déplacé les données, ce qui veut dire qu'ils peuvent déplacer des données qui ne sont presque jamais modifiées vers des secteur un peu plus usés pour libérer des secteurs tout neuf pour les données qui changent souvent.
Il faut bien voir que le mapping fait par ces algos est invisble pour le système. Le système verra toujours un grand bloc de stockage continu, le wear-leveling fais de la translation d'adresses pour savoir a quel bloc physique correspond un bloc virtuel. Ce qui veut dire qu'il peut déplacer les blocs comme il veut sans perturber ton système.
Et cadeau bonus, il n'y a pas de problèmes supplémentaire de fragmentation. Le temps d'acces au blocs de données est le même quel que soit le bloc.
Il reste toujours la fragmentation du système de fichier qui doit couper les gros fichier pour les stocker sur un disque presque plein, mais même celle-ci est moins génante puisqu'il n'y a plus le problème de latence des disque mécanique qui doivent balader leur tête de lecture sur tout le disque.
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par syj . Évalué à 1.
http://www.st.com/stonline/books/pdf/docs/10122.pdf
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par windu.2b . Évalué à 1.
En contrepartie, la fragmentation doit se ressentir, non ?
bon, sur de la Flash , ça ne doit pas trop poser de pb de temps, je suppose...
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par Boa Treize (site web personnel) . Évalué à 5.
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par benoar . Évalué à 6.
Les SSD ont "apparemment" des techniques un peu mieux (je dis ça au regard du prix seulement), mais le problème c'est qu'on a absolument _aucune_ info sur ce qu'ils font, c'est pour ça que pour l'instant la mémoire flash pour moi c'est non merci : tant qu'il n'y aura pas un minimum de transparence, je ne leur ferai pas confiance. Et quelque chose me dit que si les constructeurs sont si peu locaces, c'est qu'il y a raison d'avoir peur ...
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par windu.2b . Évalué à 2.
Et/ou qu'il n'existe pas (encore ?) de modèle laissant le wear-leveling être effectué par le FS ?
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par M . Évalué à 3.
Oui tu n'a pas acces à l'interface flash bas niveau.
Et/ou qu'il n'existe pas (encore ?) de modèle laissant le wear-leveling être effectué par le FS ?
Les memoires XD, mais bon on a pas non plus d'algo de wear-leveling sous Linux (a part peut etre UBI).
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par Sarcastic . Évalué à 2.
https://linuxfr.org//2008/04/04/23938.html
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par M . Évalué à 3.
# Et le swap ?
Posté par dyno partouzeur de drouate . Évalué à 10.
Depuis, j'ai mis mon swap sur un ramdisk, et je dois dire que je suis très satisfait du résultat, sauf que je sais pas si c'est à cause de ça mais parfois le clavier se blo
[^] # Re: Et le swap ?
Posté par outs . Évalué à 1.
[^] # Re: Et le swap ?
Posté par olebrun . Évalué à -1.
Ca n'a aucun interet (me trompe-je ?), tu auras juste moins de ram et ca swappera plus vite ... mais en ram ... le bordel quoi ;)
[^] # Re: Et le swap ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Et le swap ?
Posté par wismerhill . Évalué à 2.
Faut que tu donne des liens pour prouver tes dires, parce que t'es pas crédible là.
[^] # Re: Et le swap ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
http://kerneltrap.org/search/node/swap+ram
http://kerneltrap.org/node/3660
http://kerneltrap.org/node/3202
Bref, c'est vieux.
"La première sécurité est la liberté"
[^] # Re: Et le swap ?
Posté par wismerhill . Évalué à 3.
[^] # Re: Et le swap ?
Posté par olebrun . Évalué à 1.
[^] # Re: Et le swap ?
Posté par Rémi baudruche . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.