Discussion :

[dafpp]

Bonjour,
je suis surpris de ce qui m'arrive: voilà que je n'ai plus de place sur mon disque dur.
Je suis sous Open Solaris 11 en machine virtuel, et je n'ai pas vérifié mon espace disque dernièrement donc je ne sais pas si c'est venu d'un coup ou au fur et à mesure.
Donc je regarde mes pool, je vois 98% occupé sur rpool...
Je fais un 'du' sur la racine - qui ne s'est toujours pas terminé - et j'ai pû remarquer déjà: 404G sur /proc.
Pourquoi pas, mais le soucis c'est que rpool ne fait normalement que 20G ...

Donc je ne suis pas sûr de comprendre ce qui se passe, de même que la commande 'du' a énormément de mal à me donner un résultat pour /usr - alors que /proc est quasiment immédiat - pour un résultat du.

Donc impossible de modifier n'importe quel fichier, ni de regarder un manuel, etc ...
Je m'en suis aperçu il y a moins de 30 minutes, donc j'attends les résultats tout de même pour opérer - quoi que étant un débutant, je ne vais pas toucher à proc ... - je n'ai donc toujours pas redémarrer quoi que ce soit - est ce vraiment une solution ? non je ne pense pas - mais je reviendrai sur un dernier snapshot s'il faut, pour voir tout ça - mais comme je l'ai dis j'attends tout d'abbord.

Ce que je ne suis pas sûr de comprendre d'ailleurs, sont les résultats de 'du'. Donc comme Solaris aime respecter les normes POSIX à leurs manière, je ne sais pas si ça vient de ça, ou plutôt moi qui n'arrive pas à faire le lien sur les résultats que je reçois - je doute en effet sur ce que je sais après avoir vu 404G alors que ... je suis sur un pool de 20G, donc ... :s.
Exemple:

Code :

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

1
2
du -s /proc/
847111901       /proc

Code :

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

1
2
du -sh /proc/
404G   /proc

J'ai lu dans le manuel (die.net) - je ne peux plus sur ma machine - que le résultat été en 'binary prefixes' - je sais pas si c'est comme ça qu'on dit vraiment - et que h (human readable) faisait lui aussi un résultat du même type - 1024 - car comme indiqué pour l'option --si - que je n'ai pas le droit sur Solaris - ce n'est pas un résultat en 2^ mais en 10^, donc j'en conclu très bien qu'avec l'option -h on a un résultat du même type que par défaut normalement - hormis le petit G,K,ou M, etc ...

-Bref- Je ne sais pas si ça vient donc de ma compréhension toute bête sur le problème, ou de l'état du système actuel.

-tout le temps que j'ai pû passé à écrire ce post, je n'ai toujours pas de réponses de:

Code :

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

du -s /usr

, je ne sais pas ce que je dois faire.
Ça n'est pas tout de remettre un ancien état du système - en utilisant un snapshot - mais j'aimerai comprendre ce qui arrive.
Je ne sais pas si je dois attendre, assis sur ma chaise, alors que je devrai travailler - sur mon sujet de stage en l’occurrence.

Donc dans ce genre de situation: disque pleins, résultat 'du' horriblement lent, impossibilité d'écrire - ouverture manuels, fichiers, ...; comment dois-je procéder: supprimer des choses - dans /proc ? ça parait un peu violent - revenir un ancien snapshots, comment éviter ce genre de chose.

Je ne sais pas vraiment comment le disque s'est rempli d'une telle manière, et je ne pense pas qu'à partir mon post, quelqu'un puisse en déduire quoi que ce soit, mais ce genre de soucis, m'empêche de travailler, et donc me ralentis dans le projet final que je dois accomplir; ce que je suis sûr c'est des résultats que m'apporte les commande des pool de type zfs:

Code :

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

1
2
3
4
NAME        SIZE  ALLOC   FREE  CAP  DEDUP  HEALTH  ALTROOT
rpool      19,9G  19,5G   374M  98%  1.00x  ONLINE  -
zfs_audit  9,94G  1,15G  8,78G  11%  1.00x  ONLINE  -
zfs_pool   49,8G  3,56M  49,7G   0%  1.00x  ONLINE  -

-Hors je ne vois pas de dépassement de 400G - qui n'est certes pas possible, donc je ne comprends pas du tout.

Je suis fort confus, et je me retrouve coincé, ne sachant pas quoi faire intelligemment .

Merci de me donner un coup de main,
merci.

Cordialement,
Pascal Diogo Antunes (Dafp)

[dafpp]

Alors je suis revenu sur un ancien snapshots, après avoir perdu patience avec la commande 'du':
Le disque est moins rempli, mais ça peut revenir rapidement:
- /proc fait 202G ... donc est ce de mon résultat 'du' ou est ce 'normal' ?
- /usr fait 2.4G, je n'ai pas pû savoir avant de revenir en arrière mais sans doute la lenteur venait de la saturation passé.
- /var fait 10G, les 9G vienne de Apache: /var/apache2/2.2/logs/error_log.

Que dois-je faire: j'évite les logs ? Je réduit le nombre d'erreurs écrite ?

Edit:
Malheureusement le soucis ne venait pas de là ...

Code :

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

1
2
3
zpool list rpool
NAME    SIZE  ALLOC  FREE  CAP  DEDUP  HEALTH  ALTROOT
rpool  19,9G  19,5G  374M  98%  1.00x  ONLINE  -

Code :

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

1
2
3
4
5
6
7
8
9
10
11
zfs list -r rpool
NAME                              USED  AVAIL  REFER  MOUNTPOINT
rpool                            19,6G      0  39,5K  /rpool
rpool/ROOT                       17,8G      0    31K  legacy
rpool/ROOT/solaris               17,8G      0  2,81G  /
rpool/ROOT/solaris-backup-1        58K      0  2,85G  /
rpool/ROOT/solaris-backup-1/var     1K      0   120M  /var
rpool/ROOT/solaris/var           14,6G      0  14,4G  /var
rpool/dump                        774M  23,8M   750M  -
rpool/export                      172K      0    32K  /export
rpool/swap                       1,03G  32,5M  1,00G  -

Code :

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

1
2
 du -sh /var/
 1,3G   /var

Il y a un soucis entre les deux résultats, et je me retrouve avec le même soucis: mémoire saturé = pas le droit d'écriture.

Le plus beau:

Code :

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

1
2
 init 6
bootadm: error during read-only test on /: No space left on device

Edit:
En effet, tout ceci était dû au cache.
Le soucis c'est que même après suppression du log d'Apache, et avec 75% espace occupé - donc il me restait 25 ... - je me suis retrouvé au même état qu'au premier post: 98% mémoire occupé.

[jlliagre]

1: laisse tomber /proc, la taille rapportée par du n'a rien à voir avec de l'espace disque. /proc est un système de fichiers virtuel qui représente les processus en cours d'exécution.

2: Je soupçonne que tu as des snapshots qui prennent de la place. Affiche ce que retourne la commande

Code :

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

zfs list -t all

[dafpp]

Code :

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

1
2
3
4
5
6
 zfs list -t snap
NAME                                         USED  AVAIL  REFER  MOUNTPOINT
rpool/ROOT/solaris@install                  54,1M      -  1,40G  -
rpool/ROOT/solaris@2012-04-10-10:42:09       295M      -  2,85G  -
rpool/ROOT/solaris/var@install               161M      -   215M  -
rpool/ROOT/solaris/var@2012-04-10-10:42:09  37,1M      -   120M  -

Non mais c'est bon, j'ai "réglé" le problème. C'était le fichier qui était trop imposant, et qui remplissait la mémoire. Il fallait ensuite redémarrer, sinon c'était toujours en mémoire - je ne sais pas comment ça marche mais le résultat était là.

Apache doit enregistrer trop d'erreurs, donc soit il y a des erreurs dans les pages que apache sert, ou ça vient d'apache lui même. Dans les deux cas, faut que je sois attentif à éviter que ça fasse le même problème.

Merci pour les renseignements.

[jlliagre]

C'était le fichier qui était trop imposant, et qui remplissait la mémoire.

Qui remplissait le disque tu veux dire.

Il fallait ensuite redémarrer, sinon c'était toujours en mémoire - je ne sais pas comment ça marche mais le résultat était là.

Oui. Un fichier occupe toujours de la place sur disque tant qu'un processus écrit dedans (ou simplement le maintient ouvert). Effacer le fichier ne libère pas de place immédiatement. C'est le comportement normal de tous les Unix.

[dafpp]

Oui pardon 'disque' je voulais dire - pas de malentendu, mais in-appropriation du terme.

En effet ça parait logique, donc j'aurai très bien pû redémarrer le service httpd, ça aurait tout aussi bien marcher.

merci pour ces précisions.