|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Invité de passage
![]() Inscription : février 2007 Messages : 3 ![]() |
Bonjour,
J'administre actuellement un serveur sous Red Hat AS4 et j'ai des problèmes pour déterminer l'espace disque disponible: - la commande # df renvoi: Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur /dev/mapper/VolG 67862104 55700412 8714500 87% / /dev/cciss/c0d0p1 101086 12528 83339 14% /boot none 517320 0 517320 0% /dev/shm - tandis que # du / -s renvoi: 17427947 Je ne comprend rien: l'espace occupé est de 55.700.412K ou 17.427.947K sur mon disque ?? Merci pour votre aide |
|
|
00
|
|
|
#2 |
|
Expert Confirmé Sénior
![]() francois Ingénieur systèmes et réseaux Inscription : juillet 2006 Messages : 3 546 ![]() |
je vois gros comme une maison le coup qu'une des mesure se fasse en Kiloblocks et l'autre en kilo-octet
si par exemple tu as 4096 block de 512 octets ça fait 2Ko il est normal d'avoir un rapport de 1 à 2 entre les mesures.... sans parler des variations dans le temps entre les mesures... verifies bien les unités de mesure demandées utilise la notation humaine si elle est disponnilble (-h en principe) ça donne des resultats du genre 4.3Go 5.2Ko etc...etc.... ça permettra déjà d'éliminer ou de confirmer l'hypothèse d'un soucis de mesure. |
|
|
00
|
|
|
#3 |
|
Invité de passage
![]() Inscription : février 2007 Messages : 3 ![]() |
Malheureusement c'est pas aussi facile. On se la refait en "human readable":
# du / -sh 17G / # df -h Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/mapper/VolGroup00-LogVol00 65G 54G 8,3G 87% / /dev/cciss/c0d0p1 99M 13M 82M 14% /boot none 506M 0 506M 0% /dev/shm ARG ! Pas de probleme d'unité: les blocks sont bien en Ko J'ajouterais pour préciser qu'au moment ou j'ai découvert le problème, #df affichait 99% d'espace occupé. J'ai supprimé un fichier de log de 35Go, ce qui a réduit l'espace occupé indiqué par #du, mais n'a rien changé au résultat de #df ! (ensuite j'ai fait de la place ailleurs, en attendant) Une idée... ? |
|
|
00
|
|
|
#4 |
|
Membre émérite
![]() Inscription : janvier 2004 Messages : 990 ![]() |
La commande du / peut renvoyer une valeur bien plus grande ce que qu'on pense obtenir car par défaut il parcourt toute l'arborescence, en particulier /mnt là où se trouvent d'autres systèmes de fichiers. (Ce comportement peut être éviter avec l'option -x.)
Si l'option -c ou -L sont fournis, ça peut aussi donner un résultat plus grand que prévu. Ce qui est bizarre, c'est que dans ton cas, du renvoie une taille plus petite que df. Est-ce que les commandes du et df ne sont pas des alias ? (commande alias) Essaye de rajouter l'option --apparent-size à la commande du.
__________________
Les vaches ne peuvent PAS voler, quoi qu'elles aient pu vous raconter. |
|
|
00
|
|
|
#5 |
|
Invité de passage
![]() Inscription : février 2007 Messages : 3 ![]() |
J'ai enfin trouvé la source du problème !
C'est le syslog qui alimentait le fichier de log (ayant atteint 38Go !) qui n'avait visiblement pas libéré l'espace disque alors que le fichier log de destination était supprimé. J'ai arrêté logger ce serveur et j'ai redémarré le syslog et l'espace disque est revenu Merci aux gens qui m'ont conseillé. A la prochaine panne |
|
|
00
|
|
|
#6 |
|
Expert Confirmé Sénior
![]() francois Ingénieur systèmes et réseaux Inscription : juillet 2006 Messages : 3 546 ![]() |
ah ok
effacement du fichier alors qu'une tache l'utilise....ok donc tout à fait logique pour éviter ça je préfère ne pas effacer mais effacer le contenu par exemple avec |
|
|
00
|
|
|
#7 |
![]() Inscription : mars 2004 Messages : 1 298 ![]() |
exacte et surtout relancer le process
|
|
|
00
|
Copyright © 2000-2012 - www.developpez.com