Forum Linux.général Disque en sommeil

Posté par .
Tags : aucun
3
4
oct.
2011

Bonjour,

depuis longtemps je me pose la question d'éteindre le disque-dur de certaines machines Linux.
Je parle de ça aujourd'hui pour faire suite à http://linuxfr.org/users/jarvis/journaux/am%C3%A9liorer-vos-ordinateurs-avec-zram#comment-1275663

Actuellement je fais :
Sur certaines machines, j'ai un disque supplémentaire pour stocker des sauvegardes (en RAID ou pas, ça dépend). Comme ce disque n'est utilisé que quelques minutes par jour, sa mise en veille est activée et la partition n'est montée que lorsque nécessaire (pour être certain qu'aucun processus ne va venir le réveiller, mais ce n'est pas obligatoire).

Ce que j'aimerais faire :
J'ai des machines dont les disques ne stockent pas de données "vivantes" à part les logs. Par exemple des routeurs/pare-feu. Mais aussi les machines de sauvegardes décrites plus haut, dont les disques système ne stockent rien de particulier. Elles possèdent largement assez de RAM pour que tous les fichiers lus soient en cache. Je viens de vérifier sur l'une d'elles :

$ uptime
 22:07:36 up 69 days,  7:50,  1 user,  load average: 0.00, 0.00, 0.00
$ free -m
             total       used       free     shared    buffers     cached
Mem:           121         94         27          0         23         45
-/+ buffers/cache:         26         95
Swap:            0          0          0

 
Et sur une autre :

$ uptime
 22:09:51 up 69 days,  8:16,  1 user,  load average: 0.00, 0.00, 0.00
$ free -m
             total       used       free     shared    buffers     cached
Mem:           993        940         53          0        568        170
-/+ buffers/cache:        200        792
Swap:            0          0          0

 

Solution 1
Ne pas mettre de disque dans la machine --> booter sur le réseau
Très bonne idée, que j'applique déjà pour certains serveurs.
Problème : ces machines font partie de l'infrastructure qui ne doit pas casser lorsque d'autres sont HS. Et les deux machines dont je viens de copier/coller les infos sont dans des sites sur lesquels je n'ai pas de contrôle sur le reste.

Solution 2
Utiliser des SSD
Problème : ce sont des machines de récupération. Du matériel à zéro euros et c'est laaaargement suffisant. J'ai moyennement envie d'acheter des SSD, de faire des déplacements juste pour ça, etc. Et pour une nouvelle machine, pareil. Par principe.
Excuse foireuse.

Solution 3
Utiliser une clef USB comme disque système (et pour booter, et en cas de machine récalcitrante, débuter le boot avec un cd ou même le disque-dur d'origine avant de l'éteindre).
Globalement je pense que c'est une bonne idée. Ca coûte vraiment pas cher (il y a moins de 1 Go utilisé sur les deux machines citées plus haut).
Problème : je ne suis pas certain que les clefs USB supportent de nombreuses écritures, en particulier pour les logs. Mais le vrai problème est que je veux le faire avec un disque-dur.

Solution 4
La solution à laquelle je pense me semble un peu compliquée.

Le principe est de faire en sorte que les fichiers utilisés en lecture soient présents en mémoire : cache ou système de fichier en RAM.
Le tout sans nécessité d'alléger le système de fichiers (par exemple pas besoin de supprimer les pages de manuels et autres documentations) afin que les choses restent simples et relativement standards.

Il y a peu d'écritures, et elles ne sont pas vraiment importantes (en gros, ce sont les logs, qui sont déjà envoyés à l'extérieur). Les fichiers utilisés en écriture sont écrits en mémoire, et répliqués via le réseau par sécurité. Eventuellement une fois par semaine via une tâche cron le disque se remet en route pendant quelques instants afin de purger/synchroniser les écritures.
Je fais déjà de la réplication via le réseau avec le RAID logiciel, options write-mostly et bitmap. Ca marche bien même en cas de coupure. Sinon avec rsync+inotify ou je ne sais quoi. A creuser.
On pourrait admettre qu'en cas de coupure réseau (rare), on repasse en mode écriture directe sur le disque.
Pour écrire en mémoire, il faut soit un équivalent de ramfs, soit pouvoir régler le cache pour qu'il garde les modifications perpétuellement (pas trouvé).
On fait comment lors après une extinction brutale ? On va chercher les modifications sur le réseau ? Ou on oublie carrément car dans mon cas les données écrites se limitent aux logs et aux fichiers de verrou et de pid. Mais pour d'autres besoin ce n'est peut-être pas super.

 
Voilà où en sont mes réflexions.
Je n'ai pas poussé plus loin car les disques-dur que j'utilise très peu ne sont encore jamais tombés en panne. J'ai demandé à une autre personne qui utilise le même genre de machine (du moins c'est moi qui ai copié) et il fait le même constat.
C'est plus pour le principe et la découverte.

 

  • # Un sujet original

    Posté par . Évalué à 1.

    Ce n’est pas tout-à-fait la même problématique, mais je pense que ça devrait t’intéresser. J’avais abandonner à l’époque par manque de RAM, mais j’ai pris quelques notes. Il s’agit d’un portable où le but du jeu et que le disque dur s’arrête au bout de 1/2 minutes et se réveille le moins souvent possible (une fois toutes les 1/2 heures par exemple).

    Attention tout ceci est dangereux en cas d’arrêt brutal de l’ordinateur ! Globalement vaut mieux prévoir un système sur batterie qui puisse s’éteindre proprement. Mais là il n’y a pas d’alternatives : si on ne veut pas utiliser le disque on ne peut pas garantir la sécurité des données.

    Options de montage :
    — noauto_da_alloc empêche la détection automatique des cas pénibles d’écriture/renomage pour conserver le fichier et l’écriture forcée dans ces cas là, à tester ;
    — commit=n en secondes augmente le temps entre les écritures effectives ;
    — relatime évite d’écrire à chaque accès exclusivement en lecture.
    (barrier=0/nobarrier)

    /etc/ld.so.preload doit contenir /usr/lib/libeatmydata/libeatmydata.so pour empêcher les appel à sync de réveiller le disque dur (cf. pb. de Firefox avec Sqlite).

    Contenu du fichier systctl :
    vm.laptop_mode=5 (y compris sur une machine « standard », de souvenir ça oblige à vider les caches en écriture lorsque le disque dur se réveille pour x ou y raison)
    vm.dirty_writeback_centisecs=n00
    vm.swappiness=100
    vm.dirty_ratio=50
    (vm.dirty_background_ratio,vm.dirty_expire_centiseconds,vm.dirty_ratio)

    Un tmpfs pour /tmp dans fstab ?

    Pour surveiller les accès :
    — while [ 1 ]; do; iotop -bn2 -d1 -atoqqq; done ;
    — inotify ;
    — ltrace et strace ;
    — lsof.

    Il y avait encore beaucoup de choses à faire, notamment certains logiciels continuaient à réveiller le disque dur, je n’avais pas pu identifier pourquoi. Mais sur un serveur, une fois les données en cache et en fonction de l’utilisation de la machine ça peut peut-être marcher.

    • [^] # Re: Un sujet original

      Posté par . Évalué à 2.

      Si ça peut aider pour la réflexion : j'ai ici chez moi une machine que j'ai configurée en filer (a l'origine ce n'était pas pour ça ...) sur laquelle j'ai mis une carte Compact Flash à la place du disque système, et utilisé un FS en RAM pour les données qui bougent (/var/tmp, /tmp, et d'autres FS qui passent leur temps à bouger).

      L'idée était pour moi d'avoir une machie sans disque et d'envoyer les logs sur une autre machine, voire les dupliquer sur un site distant, mais je n'ai pas encore eu le temps de le faire : mais je me suis posé les même squestions.

      La compact flash coute moins cher qu'un SSD (on trouve des adaptateurs IDE.CF pour une bouchée de pain), est très silencieuse, et permet un démarrage plus rapide qu'un disque dur. J'aurais pu mettre l'OS sur clé USB mais certains matériels de récup ne peuvent pas booter sur USB d'une part, et d'autre part, je ne trouve pas ça élégant.

      Pour l'écriture des logs je suis en train de réfléchir à une solution alternative à la syslog déportée : l'idée m'est venue il y a peu, et nécessitera probablement que je sorte le fer à souder ... :)

  • # live-cd

    Posté par (page perso) . Évalué à -1.

    Ce que tu veux faire ressemble fortement au comportement des live-cd !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.