Journal Arret total du disque dur

Posté par Stibb le 24 mars 2004 à 17:42.

Étiquettes : aucune

mar.

2004

Bonjour chers Journeux

J'ai un veux serveur dont je tente de réduir et la consommation et le bruit. Ce serveur ne sert que de routeur/firewall.
Et j'ai mis un vieux disque dur qui fait un boucan d'enfer (dur dur de dormir à coté)
Donc je me suis dit: tiens, je vais arreter tous les démons pas utile et le disque il va s'arreter de lui même (avec un petit hdparm -S ...).
Et bien nan, pas moyen.

y a quasiment aucun serveur qui tourne:

1 ? S 0:04 init [2]
2 ? SW 0:00 [keventd]
3 ? SWN 0:00 [ksoftirqd_CPU0]
4 ? SW 0:00 [kswapd]
5 ? SW 0:00 [bdflush]
6 ? SW 0:00 [kupdated]
9 ? SW 0:00 [khubd]
10 ? SW 0:01 [kjournald]
361 ? S 0:00 /usr/sbin/ez-ipupdate -d -c /etc/ez-ipupdate/default.conf -F /var/run/ez-ipupdate/default.pid
369 ? S 0:00 /usr/sbin/inetd
637 ? S 0:00 /usr/sbin/sshd
787 ? S 0:00 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf
875 tty1 S 0:00 -bash
877 tty3 S 0:00 /sbin/getty 38400 tty3
878 tty4 S 0:00 /sbin/getty 38400 tty4
879 tty5 S 0:00 /sbin/getty 38400 tty5
883 tty6 S 0:00 /sbin/getty 38400 tty6
1233 ? S 1:49 /usr/local/sbin/pppoa -I eth2
914 ? S 0:00 pppd file /etc/ppp/peers/adsl
3406 ? S 0:00 /usr/sbin/named
3499 tty2 S 0:00 /sbin/getty 38400 tty2
4046 ? S 0:00 /sbin/portmap
4451 ? S 0:00 sshd: root@pts/0
4453 pts/0 S 0:00 -bash
4457 pts/0 R 0:00 ps ax
ka

juste les outils pour la connexion internet adsl, et un serveur ssh et webmin.

Et bien voilà: quand je fais un hdparm -Y /dev/hda, le disque s'arrete, mais il redémarre quelques temps après (qques secondes, quelques minutes)... et j'aimerais bien savoir quel est le %£# de processus qui empeche mon disque dur de dormir tranquille.

J'aimerais bien avoir un filemonitor. Le seul que j'ai trouvé c'est celui de systernals... mais je n'ai même pas la place de mettre un serveur X, et le programme de systernals... fonctionne que sous X...

J'ai bien essayer avec strace -p mais il me sort trop d'info et surtout, il est trop ciblé sur un processus particulier

En fait à terme, le but est d'avoir un serveur qui dort tout le temps, puis qui se réveille quand il y a une requete sur un des serveurs:
- apache (site avec un wiki)
- mysql
- cvs
- ssh
- ftp
- webmin
Le plus important c'est que tous ces serveurs DORMENT sans AUCUN acces au disque pendant plusieurs jours, et qu'ils se réveillent (avec éventuellement un temps de lattence importante à la première connexion) quand j'aurais besoin d'eux...

Mais ça se sera la prochaine étape...

Donc voilà, si ce journal pouvait m'indiqué quelques pistes, je pourrais mieux dormir :)

Caractéristiques:
Debian Sid - kernel 2.4.25
/ en ext3fs avec l'option noatime

merci merci!!

# Re: Arret total du disque dur

Posté par Sébastien Koechlin le 24 mars 2004 à 17:51. Évalué à 1.

Regarde dans les sources du kernel 2.4, c'est fait pour les portables initialement, mais ça va surement répondre à tes besoins. Il y a la description d'un mode qui écrit moins sur le disque ET une méthode pour savoir qui fait des accès disque.

Il faut aussi remplacer bdflush par noflushd qui est disponible il me semble dans la SID.

Documentation/laptop-mode.txt :

The main knob is /proc/sys/vm/laptop_mode. Setting that to 1 switches the vm (and block layer) to laptop mode. Leaving it to 0 makes the kernel work like before.

It can happen that the disk still keeps spinning up and you don't quite know why or what causes it. The laptop mode patch has a little helper for that as well, /proc/sys/vm/block_dump. When set to 1, it will dump info to the kernel message buffer about what process caused the io.
# LOGs !!!

Posté par Beurt le 24 mars 2004 à 17:54. Évalué à 1.

Je pense que tu dois avoir syslogd qui écrit dans var/log/whatever et sans doute dans ta crontab un certain nombre de processus de chekup, non ?
Tout ce petit monde, quand ça ne lit pas sur le disque, au moins ça y écrit les logs !
- [^] # Re: LOGs !!!
  
  Posté par Stibb le 24 mars 2004 à 18:00. Évalué à 1.
  
  j'ai viré syslogd et crond
  (/etc/init.d/syslogd stop
  /etc/init.d/cron stop)
  alors à moins qu'ils ne se relancent tous seuls, devraient pas exister ces troubles fetes là)
  - [^] # Re: LOGs !!!
    
    Posté par philz le 24 mars 2004 à 19:05. Évalué à 3.
    A une époque j'avais écrit le petit script ci dessous pour trouver le coupable (depuis j'ai acheté un disque dur de portable pour dormir tranquille ...) :
```
#!/usr/bin/perl

use strict;
use IO::File;

my $command = "/sbin/hdparm -C /dev/hda";
my $timer = 0;
my $timerActive = 0;
my $dateActive = "";
my $state = getState();

autoflush STDOUT;

print "Starting state is $state\n";

while (sleep 1) {
  my $newstate = &getState();
  if ($state ne $newstate) {
    if ($newstate eq "active") {
      &writeLog();
    } else {
      &reset();
    }
    $state = $newstate;
  }
  $timer++;
}

sub writeLog {
  return unless $dateActive;
  my $date = `date +"%F %T"`;
  chomp $date;
  my $files = `find / -mmin -3 -xdev`;
  $files =~ s/\n/ /g;
  $files = substr $files, 0, 120;
  {
    printf "[$dateActive] Active during  %5d seconds\n", $timerActive;
    printf "[$date] Standby during %5d seconds", $timer;
    print ", wake-up by $files\n";
  }
  $timer = 0;
}

sub reset {
  $timerActive = $timer;
  $dateActive = `date +"%F %T"`;
  chomp $dateActive;
  $timer = 0;
}

sub getState {
  my $state = `$command`;
  if ($state =~ m/standby/) {
    return "standby";
  } elsif ($state =~ m/active\/idle/) {
    return "active";
  } else {
    die "Erreur : $state";
  }
}
```
    - [^] # Re: LOGs !!!
      
      Posté par M le 24 mars 2004 à 22:34. Évalué à 1.
      
      lsof permet aussi de voir les fichiers ouvert, et donc ceux qui sont suceptible de reveiller un dd
      - [^] # Re: LOGs !!!
        
        Posté par Stibb le 24 mars 2004 à 22:58. Évalué à 1.
        
        oui y a pas moyen de lui faire cracher des informations sur les accès?
        parce qu'il me sort une quantité énorme de fichier ouvert, comment s'en sortir et quel fichier aura la plus grand probabilité d'être lu/écrit...
        
        [^] # Re: LOGs !!!
        
        Posté par philz le 25 mars 2004 à 09:28. Évalué à 1.
        
        avec lsof je ne sais pas, mais le but de mon "find / -mmin -3" était exactement ça (chercher tous les fichiers qui ont été modifiés dans les 3 dernières minutes).
# Re: Arret total du disque dur

Posté par __caffeine__ le 24 mars 2004 à 18:09. Évalué à 1.

Bon, c'est peut-être débile, mais pourquoi pas mettre ton /var/www dans on ramdisk (si tu as la place bien sûr) ?
- [^] # Re: Arret total du disque dur
  
  Posté par Paul Rouget le 24 mars 2004 à 20:11. Évalué à 1.
  
  Hum... et pourquoi pas TOUT dans un ram disk ?
  Un systeme minimal, c'est possible.
  - [^] # Re: Arret total du disque dur
    
    Posté par Stibb le 24 mars 2004 à 21:21. Évalué à 1.
    
    et comment faire à partir de ce qui est déjà installé (apt peut pas aider?)
# Re: Arret total du disque dur

Posté par Troy McClure (site web personnel) le 24 mars 2004 à 18:15. Évalué à 2.

à ma connaissance le ext3 (et tous les fs journalisés) solicitent régulièrement le disque dur. Essaye de le monter en ext2 pour voir.
- [^] # Re: Arret total du disque dur
  
  Posté par Stibb le 24 mars 2004 à 21:29. Évalué à 1.
  
  arg le probleme du ext2fs c'est qu'il n'est pas très robuste en cas de plantage (arret de l'ordi violement,..)
  
  Et en théorie, quand il n'y a pas d'activité avec le disque dur... ben y a aucune raison qu'il écrive ou lise quoi que ce soit sur le disque!
  - [^] # Re: Arret total du disque dur
    
    Posté par fmaz fmaz le 25 mars 2004 à 07:49. Évalué à 1.
    
    Ben prends un système de fichier en mode synchrone.
    
    C'est ce qui existe de plus robuste en cas de plantage.
    
    extrait de man mount.
    "the sync option today has effect only for ext2, ext3 and ufs"
    
    donc un ext2 en synchrone marche.
    
    Frédéric
    - [^] # Re: Arret total du disque dur
      
      Posté par Stibb le 25 mars 2004 à 10:42. Évalué à 1.
      
      c'est pas le contraire de ce que je veux ça? dès qu'il y a une modif sur le filesystem, il l'écrit... hors, moi j'aimerais qu'il garde tout ça en cache et qu'il flush le moins souvent possible....
# Re: Arret total du disque dur

Posté par SubBass le 24 mars 2004 à 22:59. Évalué à 1.

ma réponse à deux balles -en fait elle répond à rien du tout- :
prends un seagate ! je n'ai jamais eu disque dur plus silencieux ( au nombre de 6 sur mon serveur, le tout en silence total du moment que la tour est fermée)
- [^] # Re: Arret total du disque dur
  
  Posté par mansuetus (site web personnel) le 24 mars 2004 à 23:11. Évalué à 1.
  
  pourquoi n'ai-je pas lu cette dépèche quand j'ai acheté mon pécé ?
  
  mon disque dur me pête le...........
# Re: Arret total du disque dur

Posté par _alex le 25 mars 2004 à 00:03. Évalué à 1.

Pour la consommation, j'ai fait quelques mesures avec un PC que je destine à faire serveur :
- Alim 300Watt Nexus : environ 60Watt
- Alim 230Watt assez veille : environ 55Watt.
- à mon avis avec une alim de 100W on gagne encors 5Watt. Le problème c'est que c'est alim coute très chère : il faudrait laisser tourner le PC tourné pendant plus 2 ans 24/24 pour rentabilité l'achat.

Mesure avec disque dur en standby, sans activité CPU après le boot de Linux. (ampèmetre en série sur la prise du 220)

Le PC est un duron 750 et une carte mère KT133A. Il y a une carte réseau, un disque seagate 120go, et 2 barettes de SDRAM.

Pour le disque dur j'ai le même problème. Je pense mettre un maximum de service dans un ramdisk compressé avec un cloop à la knoppix (si j'ai la motivation...)

Je voudrais aussi underclocker le CPU, mais je n'ai pas trouvé le moyen.
# Re: Arret total du disque dur

Posté par Stibb le 25 mars 2004 à 10:41. Évalué à 1.

merci tout le monde
j'ai essayé l'option noatime de mount pour la partition / et apparament, les accès disque se font vraiment moins souvent. Je vais donc essayer de remettre petit à petit des services en route (cron, apache,...) voir si ça continue a bien marcher (ça fait du bien de dormir en silence...)

Suivre le flux des commentaires

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