L'occupation de ma partition montée sur /tmp augmente régulièrement.
C'est un volume logique. Il y a une semaine ou deux, elle avait conservé
sa taille initiale (100M). J'ai du la remonter à 500, puis 800 hier
soir, avec actuellement une occupation (au sens de df) de 560M. Hier
soir, lorsque j'ai stoppé la machine, j'avais 496M. Donc 64M de mieux au
reboot, si je puis dire. Évidemment, un `du -sh /tmp` ne donne quasiment
rien.
Un `lsof -a +L1` sur /tmp ne donne quasiment rien, que des fichiers
apache2 ou mysqld. L'arrêt de ces services ne rend rien de probant, et
surtout pas de l'espace disque.
Avant de stopper la machine, j'ai tenté, hier soir, de me mettre sur le
terminal, couper X et un certain nombre de services (postfix, mysql,
apache, cron, clamav, nut, dnsmasq, memcached, libvirt). Sans succès.
/dev/mapper/debian-lvtmp on /tmp type xfs (rw,relatime,inode64,noquota)
Je reviens sur la configuration en volume comme facteur. Je me dis que si je ne vois rien concernant le système de fichiers (fichiers effacés mais toujours ouverts par exemple), c'est peut-être que l'augmentation est due à des metadonnées de lvm2.
Je ne vois pas comment. Les méta-données de LVM sont stockées en dehors des volumes logiques et leurs systèmes de fichiers.
Je soupçonne plutôt le système de fichiers lui-même. Peut-être un journal qui grossit, un snapshot qui s'ajoute, (si ça existe sur XFS)...
Tu peux démarrer un autre système (live par exemple) dont tu es sûr qu'il n'écrit rien sur ces volumes, et tu pourras voir si l'espace occupé affiché par du et df coïncide.
Jean-Michel OLTRA a écrit :
Et quel est le FS ?
xfs
/dev/mapper/debian-lvtmp on /tmp type xfs (rw,relatime,inode64,noquota)
Je reviens sur la configuration en volume comme facteur. Je me dis que
si je ne vois rien concernant le système de fichiers (fichiers effacés
mais toujours ouverts par exemple), c'est peut-être que l'augmentation
est due à des metadonnées de lvm2.
Je ne vois pas comment. Les méta-données de LVM sont stockées en dehors
des volumes logiques et leurs systèmes de fichiers.
Je soupçonne plutôt le système de fichiers lui-même. Peut-être un
journal qui grossit, un snapshot qui s'ajoute, (si ça existe sur XFS)...
Tu peux démarrer un autre système (live par exemple) dont tu es sûr
qu'il n'écrit rien sur ces volumes, et tu pourras voir si l'espace
occupé affiché par du et df coïncide.
/dev/mapper/debian-lvtmp on /tmp type xfs (rw,relatime,inode64,noquota)
Je reviens sur la configuration en volume comme facteur. Je me dis que si je ne vois rien concernant le système de fichiers (fichiers effacés mais toujours ouverts par exemple), c'est peut-être que l'augmentation est due à des metadonnées de lvm2.
Je ne vois pas comment. Les méta-données de LVM sont stockées en dehors des volumes logiques et leurs systèmes de fichiers.
Je soupçonne plutôt le système de fichiers lui-même. Peut-être un journal qui grossit, un snapshot qui s'ajoute, (si ça existe sur XFS)...
Tu peux démarrer un autre système (live par exemple) dont tu es sûr qu'il n'écrit rien sur ces volumes, et tu pourras voir si l'espace occupé affiché par du et df coïncide.
Jean-Michel OLTRA
Bonjour,
Le dimanche 20 septembre 2015, Pascal Hambourg a écrit...
Je ne vois pas comment. Les méta-données de LVM sont stockées en dehors des volumes logiques et leurs systèmes de fichiers.
Oui, j'ai vu ça.
Je soupçonne plutôt le système de fichiers lui-même. Peut-être un journal qui grossit, un snapshot qui s'ajoute, (si ça existe sur XFS)...
Possible. Je vais voir si je peux évaluer l'évolution de la taille des logs du fs.
Tu peux démarrer un autre système (live par exemple) dont tu es sûr qu'il n'écrit rien sur ces volumes, et tu pourras voir si l'espace occupé affiché par du et df coïncide.
Bonne idée. Je ferai la manip au prochain reboot (demain).
J'ai désactivé le montage au boot d'un des volumes. Je verrai si ça induit un changement.
Merci.
Au fait : personne en LVM et XFS sur la liste…?
-- jm
Bonjour,
Le dimanche 20 septembre 2015, Pascal Hambourg a écrit...
Je ne vois pas comment. Les méta-données de LVM sont stockées en dehors
des volumes logiques et leurs systèmes de fichiers.
Oui, j'ai vu ça.
Je soupçonne plutôt le système de fichiers lui-même. Peut-être un
journal qui grossit, un snapshot qui s'ajoute, (si ça existe sur XFS)...
Possible. Je vais voir si je peux évaluer l'évolution de la taille des
logs du fs.
Tu peux démarrer un autre système (live par exemple) dont tu es sûr
qu'il n'écrit rien sur ces volumes, et tu pourras voir si l'espace
occupé affiché par du et df coïncide.
Bonne idée. Je ferai la manip au prochain reboot (demain).
J'ai désactivé le montage au boot d'un des volumes. Je verrai si ça
induit un changement.
Le dimanche 20 septembre 2015, Pascal Hambourg a écrit...
Je ne vois pas comment. Les méta-données de LVM sont stockées en dehors des volumes logiques et leurs systèmes de fichiers.
Oui, j'ai vu ça.
Je soupçonne plutôt le système de fichiers lui-même. Peut-être un journal qui grossit, un snapshot qui s'ajoute, (si ça existe sur XFS)...
Possible. Je vais voir si je peux évaluer l'évolution de la taille des logs du fs.
Tu peux démarrer un autre système (live par exemple) dont tu es sûr qu'il n'écrit rien sur ces volumes, et tu pourras voir si l'espace occupé affiché par du et df coïncide.
Bonne idée. Je ferai la manip au prochain reboot (demain).
J'ai désactivé le montage au boot d'un des volumes. Je verrai si ça induit un changement.
Merci.
Au fait : personne en LVM et XFS sur la liste…?
-- jm
Francois Lafont
On 20/09/2015 10:44, Jean-Michel OLTRA wrote:
espinasse:~$ lsof /tmp
J'avais indiqué la commande « lsof | grep /tmp », pas la commande ci-dessus. Par ailleurs, et là par contre je ne l'ai pas indiqué, il faut mieux lancer la commande en tant que root.
Je suis très surpris que la commande « lsof /tmp » que tu as tapée t'indique des fichiers « deleted » dans /tmp vu que normalement la commande va faire une recherche dans les fichiers qui se trouvent dans l'arborescence de /tmp et donc des fichiers forcément non deleted. Du coup ta commande me semble incohérente. Ceci étant, on voit des fichiers deleted encore utilisés dans /tmp mais ils ne sont pas bien gros.
-- François Lafont
On 20/09/2015 10:44, Jean-Michel OLTRA wrote:
espinasse:~$ lsof /tmp
J'avais indiqué la commande « lsof | grep /tmp », pas la commande
ci-dessus. Par ailleurs, et là par contre je ne l'ai pas indiqué,
il faut mieux lancer la commande en tant que root.
Je suis très surpris que la commande « lsof /tmp » que tu as tapée
t'indique des fichiers « deleted » dans /tmp vu que normalement la
commande va faire une recherche dans les fichiers qui se trouvent
dans l'arborescence de /tmp et donc des fichiers forcément non deleted.
Du coup ta commande me semble incohérente. Ceci étant, on voit des
fichiers deleted encore utilisés dans /tmp mais ils ne sont pas bien gros.
J'avais indiqué la commande « lsof | grep /tmp », pas la commande ci-dessus. Par ailleurs, et là par contre je ne l'ai pas indiqué, il faut mieux lancer la commande en tant que root.
Je suis très surpris que la commande « lsof /tmp » que tu as tapée t'indique des fichiers « deleted » dans /tmp vu que normalement la commande va faire une recherche dans les fichiers qui se trouvent dans l'arborescence de /tmp et donc des fichiers forcément non deleted. Du coup ta commande me semble incohérente. Ceci étant, on voit des fichiers deleted encore utilisés dans /tmp mais ils ne sont pas bien gros.
-- François Lafont
Erwan David
Le 20/09/2015 18:47, Francois Lafont a écrit :
On 20/09/2015 10:44, Jean-Michel OLTRA wrote:
espinasse:~$ lsof /tmp
J'avais indiqué la commande « lsof | grep /tmp », pas la commande ci-dessus. Par ailleurs, et là par contre je ne l'ai pas indiqué, il faut mieux lancer la commande en tant que root.
Je suis très surpris que la commande « lsof /tmp » que tu as tapée t'indique des fichiers « deleted » dans /tmp vu que normalement la commande va faire une recherche dans les fichiers qui se trouvent dans l'arborescence de /tmp et donc des fichiers forcément non deleted. Du coup ta commande me semble incohérente. Ceci étant, on voit des fichiers deleted encore utilisés dans /tmp mais ils ne sont pas bien gros.
C'est au contraire tout à fait normal : lsof va regarder dans le kernel les fichiers ouverts. Un fichier peut avoir été ouvert puis avoir été supprimé, tant qu'il est ouvert il sera sur le disque mais pas accessible. C'est très courant sur les fichiers temporaires qui n'ont pas besoin de survivre à l'instance du programme de créer le fichier puis immédiatement le supprimer. Ainsi on est sûr qu'il ne trainera pas sur le disque quelle que soit la raison de la fermeture du programme.
Le 20/09/2015 18:47, Francois Lafont a écrit :
On 20/09/2015 10:44, Jean-Michel OLTRA wrote:
espinasse:~$ lsof /tmp
J'avais indiqué la commande « lsof | grep /tmp », pas la commande
ci-dessus. Par ailleurs, et là par contre je ne l'ai pas indiqué,
il faut mieux lancer la commande en tant que root.
Je suis très surpris que la commande « lsof /tmp » que tu as tapée
t'indique des fichiers « deleted » dans /tmp vu que normalement la
commande va faire une recherche dans les fichiers qui se trouvent
dans l'arborescence de /tmp et donc des fichiers forcément non deleted.
Du coup ta commande me semble incohérente. Ceci étant, on voit des
fichiers deleted encore utilisés dans /tmp mais ils ne sont pas bien gros.
C'est au contraire tout à fait normal : lsof va regarder dans le kernel
les fichiers ouverts. Un fichier peut avoir été ouvert puis avoir été
supprimé, tant qu'il est ouvert il sera sur le disque mais pas
accessible. C'est très courant sur les fichiers temporaires qui n'ont
pas besoin de survivre à l'instance du programme de créer le fichier
puis immédiatement le supprimer. Ainsi on est sûr qu'il ne trainera pas
sur le disque quelle que soit la raison de la fermeture du programme.
J'avais indiqué la commande « lsof | grep /tmp », pas la commande ci-dessus. Par ailleurs, et là par contre je ne l'ai pas indiqué, il faut mieux lancer la commande en tant que root.
Je suis très surpris que la commande « lsof /tmp » que tu as tapée t'indique des fichiers « deleted » dans /tmp vu que normalement la commande va faire une recherche dans les fichiers qui se trouvent dans l'arborescence de /tmp et donc des fichiers forcément non deleted. Du coup ta commande me semble incohérente. Ceci étant, on voit des fichiers deleted encore utilisés dans /tmp mais ils ne sont pas bien gros.
C'est au contraire tout à fait normal : lsof va regarder dans le kernel les fichiers ouverts. Un fichier peut avoir été ouvert puis avoir été supprimé, tant qu'il est ouvert il sera sur le disque mais pas accessible. C'est très courant sur les fichiers temporaires qui n'ont pas besoin de survivre à l'instance du programme de créer le fichier puis immédiatement le supprimer. Ainsi on est sûr qu'il ne trainera pas sur le disque quelle que soit la raison de la fermeture du programme.
Daniel Huhardeaux
Le 20/09/2015 18:38, Jean-Michel OLTRA a écrit :
[...]
Au fait : personne en LVM et XFS sur la liste…?
Si, sur plusieurs serveurs en wheezy et jessie, rien noté de spécial.
-- Daniel
Le 20/09/2015 18:38, Jean-Michel OLTRA a écrit :
[...]
Au fait : personne en LVM et XFS sur la liste…?
Si, sur plusieurs serveurs en wheezy et jessie, rien noté de spécial.
Le dimanche 20 septembre 2015, 18:47:50 Francois Lafont a écrit :
On 20/09/2015 10:44, Jean-Michel OLTRA wrote: > espinasse:~$ lsof /tmp
J'avais indiqué la commande « lsof | grep /tmp », pas la commande ci-dessus.
Le résultat est le même quand /tmp est un point de montage, ce qui est le cas ici.
-- Sylvain Sauvage
Jean-Michel OLTRA
Bonjour,
Le dimanche 20 septembre 2015, Daniel Huhardeaux a écrit...
>Au fait : personne en LVM et XFS sur la liste…?
Si, sur plusieurs serveurs en wheezy et jessie, rien noté de spécial.
Je me demande si ce n'est pas une partie du problème. Il y a de nombreuses années que j'utilise XFS, et c'est bien la première fois que ça me fait ce coup là (si c'est bien lié à xfs).
Il se pourrait que mes soucis aient débuté avec l'arrivée des nouveaux noyaux 4.x Je vais voir à installer un noyau 4.0 de chez snapshot.debian.org
-- jm
Bonjour,
Le dimanche 20 septembre 2015, Daniel Huhardeaux a écrit...
>Au fait : personne en LVM et XFS sur la liste…?
Si, sur plusieurs serveurs en wheezy et jessie, rien noté de spécial.
Je me demande si ce n'est pas une partie du problème. Il y a de
nombreuses années que j'utilise XFS, et c'est bien la première fois que
ça me fait ce coup là (si c'est bien lié à xfs).
Il se pourrait que mes soucis aient débuté avec l'arrivée des nouveaux
noyaux 4.x
Je vais voir à installer un noyau 4.0 de chez snapshot.debian.org
Le dimanche 20 septembre 2015, Daniel Huhardeaux a écrit...
>Au fait : personne en LVM et XFS sur la liste…?
Si, sur plusieurs serveurs en wheezy et jessie, rien noté de spécial.
Je me demande si ce n'est pas une partie du problème. Il y a de nombreuses années que j'utilise XFS, et c'est bien la première fois que ça me fait ce coup là (si c'est bien lié à xfs).
Il se pourrait que mes soucis aient débuté avec l'arrivée des nouveaux noyaux 4.x Je vais voir à installer un noyau 4.0 de chez snapshot.debian.org
-- jm
Jean-Michel OLTRA
Bonjour,
Le dimanche 20 septembre 2015, Jean-Michel OLTRA a écrit...
Je me demande si ce n'est pas une partie du problème. Il y a de nombreuses années que j'utilise XFS, et c'est bien la première fois que ça me fait ce coup là (si c'est bien lié à xfs).
Il se pourrait que mes soucis aient débuté avec l'arrivée des nouveaux noyaux 4.x Je vais voir à installer un noyau 4.0 de chez snapshot.debian.org
Problème partiellement résolu.
Un noyau en 4.0 ne change rien.
Un xfs_repair sur le volume rend l'espace disque consommé.
Mais au reboot, l'augmentation reprend, à coup de 32M.
Donc je sais comment revenir à la normale, mais je ne sais pas vraiment ce qui pose problème, à part que ça semble lié à xfs, comme le pressentait Pascal.
-- jm
Bonjour,
Le dimanche 20 septembre 2015, Jean-Michel OLTRA a écrit...
Je me demande si ce n'est pas une partie du problème. Il y a de
nombreuses années que j'utilise XFS, et c'est bien la première fois que
ça me fait ce coup là (si c'est bien lié à xfs).
Il se pourrait que mes soucis aient débuté avec l'arrivée des nouveaux
noyaux 4.x
Je vais voir à installer un noyau 4.0 de chez snapshot.debian.org
Problème partiellement résolu.
Un noyau en 4.0 ne change rien.
Un xfs_repair sur le volume rend l'espace disque consommé.
Mais au reboot, l'augmentation reprend, à coup de 32M.
Donc je sais comment revenir à la normale, mais je ne sais pas vraiment
ce qui pose problème, à part que ça semble lié à xfs, comme le
pressentait Pascal.
Le dimanche 20 septembre 2015, Jean-Michel OLTRA a écrit...
Je me demande si ce n'est pas une partie du problème. Il y a de nombreuses années que j'utilise XFS, et c'est bien la première fois que ça me fait ce coup là (si c'est bien lié à xfs).
Il se pourrait que mes soucis aient débuté avec l'arrivée des nouveaux noyaux 4.x Je vais voir à installer un noyau 4.0 de chez snapshot.debian.org
Problème partiellement résolu.
Un noyau en 4.0 ne change rien.
Un xfs_repair sur le volume rend l'espace disque consommé.
Mais au reboot, l'augmentation reprend, à coup de 32M.
Donc je sais comment revenir à la normale, mais je ne sais pas vraiment ce qui pose problème, à part que ça semble lié à xfs, comme le pressentait Pascal.
-- jm
BERBAR Florian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 21/09/2015 13:48, Jean-Michel OLTRA wrote:
Un xfs_repair sur le volume rend l'espace disque consommé.
Si un xfs_repair rend l'espace disque consommé, il est possible que ton système de fichier soit corrompu. La partition ne comprenant pas de données persistante un "reformatage" de ta partition pourrait peut-être remettre les choses dans l'ordre.
Mais au reboot, l'augmentation reprend, à coup de 32M.
La sortie de l'utilitaire "xfs_repair" a t-elle donnée des informations ?
Un xfs_repair sur le volume rend l'espace disque consommé.
Si un xfs_repair rend l'espace disque consommé, il est possible que
ton système de fichier soit corrompu. La partition ne comprenant pas
de données persistante un "reformatage" de ta partition pourrait
peut-être remettre les choses dans l'ordre.
Mais au reboot, l'augmentation reprend, à coup de 32M.
La sortie de l'utilitaire "xfs_repair" a t-elle donnée des informations
?
Un xfs_repair sur le volume rend l'espace disque consommé.
Si un xfs_repair rend l'espace disque consommé, il est possible que ton système de fichier soit corrompu. La partition ne comprenant pas de données persistante un "reformatage" de ta partition pourrait peut-être remettre les choses dans l'ordre.
Mais au reboot, l'augmentation reprend, à coup de 32M.
La sortie de l'utilitaire "xfs_repair" a t-elle donnée des informations ?
Le lundi 21 septembre 2015, BERBAR Florian a écrit...
Si un xfs_repair rend l'espace disque consommé, il est possible que ton système de fichier soit corrompu. La partition ne comprenant pas de données persistante un "reformatage" de ta partition pourrait peut-être remettre les choses dans l'ordre.
Tous mes systèmes de fichiers seraient corrompus ? Sur tous les volumes ? Je n'y crois pas trop. Mais je vais essayer, sur /tmp. Sur les autres, ce n'est pas possible.
La sortie de l'utilitaire "xfs_repair" a t-elle donnée des informations ?
Pas vraiment. Pas d'erreur, en tous cas.
-- jm
Bonjour,
Le lundi 21 septembre 2015, BERBAR Florian a écrit...
Si un xfs_repair rend l'espace disque consommé, il est possible que
ton système de fichier soit corrompu. La partition ne comprenant pas
de données persistante un "reformatage" de ta partition pourrait
peut-être remettre les choses dans l'ordre.
Tous mes systèmes de fichiers seraient corrompus ? Sur tous les
volumes ? Je n'y crois pas trop. Mais je vais essayer, sur /tmp. Sur les
autres, ce n'est pas possible.
La sortie de l'utilitaire "xfs_repair" a t-elle donnée des
informations ?
Le lundi 21 septembre 2015, BERBAR Florian a écrit...
Si un xfs_repair rend l'espace disque consommé, il est possible que ton système de fichier soit corrompu. La partition ne comprenant pas de données persistante un "reformatage" de ta partition pourrait peut-être remettre les choses dans l'ordre.
Tous mes systèmes de fichiers seraient corrompus ? Sur tous les volumes ? Je n'y crois pas trop. Mais je vais essayer, sur /tmp. Sur les autres, ce n'est pas possible.
La sortie de l'utilitaire "xfs_repair" a t-elle donnée des informations ?
