Discussion :

[MonsieurMime]

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

[frp31]

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.

[MonsieurMime]

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... ?

[Celelibi]

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.

[MonsieurMime]

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

[frp31]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cat /dev/null > fichier

[MarcG]

exacte et surtout relancer le process

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
>fic.log
kill -HUP le-process