Reprise du message précédent :

Le 12 août 2005 - 14 h 04, iraysyvalo a écrit : Sinon, j'ai vu des manips ou ils enlevaient aussi le swap

Faut être sûr de jamais tomber à court de RAM alors !

EDIT: grillaid

Le 12 août 2005 - 15 h 05, knightmare a écrit : Le 12 août 2005 - 14 h 04, iraysyvalo a écrit : Sinon, j'ai vu des manips ou ils enlevaient aussi le swap Faut être sûr de jamais tomber à court de RAM alors ! EDIT: grillaid

Oui, mais au moins on est sur de ne pas ecrire sur le disque ..

Le 12 août 2005 - 15 h 37, iraysyvalo a écrit : Oui, mais au moins on est sur de ne pas ecrire sur le disque ..

Pourquoi ne pas monter un swap en mémoire pendant qu'on y est ?

Fais-le si ca te chante

Le 12 août 2005 - 12 h 18, iraysyvalo a écrit : Mais je vois pas bien la necessite de toutes ces manips ?? EDIT : Surtout je ne vois pas ou se fait la sauvegarde des logs vers le disque dur .. pour effacer la RAM, tu dois juste demonter le RAMfs apres non ?

Oui, alors là, je reconnais que ca à l'air compliqué. Je l'ai déjà dit, il y a surement d'autres solutions et même peut-être meilleures, je ne fais que dire ce que j'ai personnellement expérimenté.

Bon, toutes ces manips ont justement pour but de permettre la sauvegarde régulière (toutes les 24heurs chez moi) de /var. En effet la version ram de trouve sur /var->/mnt/ramfs/var et la version HDD sur /var.hdd, il suffit de copier (après avoir remonté / en RW, bien sûr).
Autre utilité de la manip, quand tu demarre, il y a un /dev et un /var qui existent.
Cela dit, j'avais cru utile de faire comme cela car /dev étant souvent accédé, j'avais besoin de le mettre sur RAMFS. Maintenant que nos linuxes ont un devfs ce n'est probablement plus utile; faudrait tester.

Le 12 août 2005 - 14 h 04, iraysyvalo a écrit : Pas la peine pour /home .. normalement il n'y a aucune ecriture dessus. Pour /, je vois pas : t'as deja ecarte les plus verbeux !

Ici, c'est un peu le même raisonnement, c'est l'expérimentation (noyau 2.4.25) qui m'a poussé à monter mes partitions RO.
En effet (est-ce toujours vrai avec un noyau 2.6 ?) les fichiers accédés en lecture seule, sont lus et cachés en RAM, mais la vm de linux va quand même s'assurer de temps à autre que le fichier du FS n'a pas évolué (ce pourrait être le cas si le FS est sur réseau), et là, le HDD se remet en marche. Potentiellement tous les executables ouverts et en cours d'execution étaient impactés, en fait tous les FD ouverts tels que l'on peut les voir avec un lsof.

De toutes facons, meme dans ce cas, on ne fait qu'une lecture non ? Je veux dire normalement, il ne sync pas dessus vu qu'ils ne sont que lus .. m'enfin, ca ne coute rien de mettre en RO ..

Effectivement devfs est deja en RAM actuellement.

Sinon, en reprenant etape par etape ton explication, je pense avoir saisi :

1- les FS a mettre en RAm sont renommes .. Prenos le cas de /var.

2- En fonctionnement normal, /var -> /mnt/ramdisk/var -> /var.hdd

3- On veut mettre nos FS en RAMfs :
3.1. On cree le RAMfs puis on le monte par-dessus /mnt/ramdisk
3.2. On copie le contenu actuel des FS depuis le disque vers /mnt/ramdisk/var (pour le cas des logs seuls, il suffit de mettre un repertoire vide )

A la sortie, on obtient /var -> /mnt/ramdisk/var (ce lien symbolique ne change pas du debut a la fin). Par contre, le remontage en 3.1 fait qu'on ne copie plus sur /var.hdd mais bien sur le RAMfs , ce qu'on voulait.

4. Au moment voulu, on copie le contenu actuel de ./var vers /var.hdd (qui aura ete remonte en RW si besoin)
5. On demonte la RAMfs et pfiuut tout est efface ..

oui, ce sont bien les étapes que j'ai utilisées.
Attention cependant à l'étape 5, il se pourrait que certains services aient encore de FD ouverts sur le fichiers du RAMFS (syslog par exemple) et dans ce cas, il ne suffit pas de recréer un /var/log/messages pour que ca marche, car il sera considéré comme un fichier différent (pas le même inode). Pour ce genre de manip il faudrait (par exemple) arreter le service, recréer les fichiers, puis redémarrer le service.
En fait, moi je n'effacais jamais mon RAMFS, ma debian (les autres distribs aussi) a un système de rotation des fichiers de log, il suffit de le configurer (ou de la hacker !!) pour le faire fonctionner correctement. Par exemple sur ma debian, la rotation se fait périodiquement (jour, semaine, mois) ou lorsque le fichier est trop gros (10Mo !! que j'ai ramené à 100Ko !!). Cette rotation suffisait à maintenir mon RAMFS petit (47Mo environ).
Maintenant, celui qui veut archiver ses logs, va adopter une stratégie un petit peu différente ...

Pour le RO, j'insiste, même si un fichier est ouvert en RO, rien n'empeche qu'un autre processus le modifie (ouverture RW donc). Bilan, le noyau force une vérification périodique des attributs de date .... et pour cela, le disque dur se remet en marche. Dans le noyau 2.6 il y a du scheduling d'accès IO, il est donc possible que cela fasse aussi office de cache, et dans ce cas, ce qu je viens de dire est obsolète (moi j'avais un 2.4).

Pour info, j'ai trouvé un DD silencieux (merci lperret), donc l'objet du topic n'est plus...

Cependant, j'essaierai de m'y mettre
Néanmoins, cela m'a l'air plus compliqué qu'il n'y paraît, au vu de mes compétences linuesques limitées...

C con j'ai pas vu le topic mais ma réponse aurait été dans le genre : "te prend pas la tete et met un seagate baracuda IV ou V !".
Perso j'ai un maxtor sata 300 Go aussi et c largement supportable ! Je te garantie que ton PAPST tu va finir par l'entendre plus que le reste