J'y ai déjà pensé, et jamais réussi à mettre en pratique (trop compliqué pour moi), en plus complexe (et je crois que certains l'ont en fait déjà mis en place):
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.
# À étendre.
Posté par Ph Husson (site web personnel) . En réponse au journal Linux presque entièrement en RAM. É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.