Forum Linux.général Linux, Ext3 et disque plein.

Posté par GTof le 22 décembre 2008 à 02:31.

Étiquettes :

déc.

2008

Bonjour a tous. J'ai un problème récurrent qui m'agace très fortement. Parfois, mon disque se rempli rapidement sans raison. Par rapidement j'entend plusieurs giga en une heure ou deux. J'ai eu beau cherché quel programme pouvait générer autant d'écritures, j'ai pas réussi a l'identifier. J'ai regardé l'espace occupé sur le disque pour savoir quels fichiers posaient problème mais ils sont dur a localiser.

Seulement quand le disque est plein, le systeme de fichier tronque tous les fichiers ouverts, ce qui m'efface regulièrement certains fichiers de configurations comme kmail, kopete, et les travaux en cours. Parfois même, quand je supprime certains fichiers, ils ne sont plus visibles mais il ne libère l'espace qu'apres un reboot. Par exemple, avant de rebooter là j'avais 0 octets de libres et après reboot, 3,8Go. J'avais bien sur supprimé tous les fichiers temporaires avant de rebooter, mais l'espace se libérait pas.

Alors voila ma question, y a t'il un moyen de dire a Ext3, quand il devient plein, de ne pas tronquer les fichiers. Ou alors y a t'il un utilitiare du genre "top" pour les access disques ? Pour info je suis sur une ubuntu Intrepid mais je ne pense pas que ca joue.

Si une âme charitable pouvait me donner quelques conseils pour pister les programmes zélés ou dire a Ext3 de ne pas tout effacer comme un con, je lui en serait tres reconnaissant.

Merci bien.

# filelight et lsof

Posté par wismerhill le 22 décembre 2008 à 08:26. Évalué à 5.

filelight est un programme KDE (il en existe d'autres) qui affiche graphiquement l'usage du disque et permet de repérer facilement les répertoires/fichiers qui utilisent le plus d'espace.
Ensuite avec la commande lsof tu peux essayer de voir si ces fichiers sont encore ouverts par un processus.
- [^] # Re: filelight et lsof
  
  Posté par Fabimaru (site web personnel) le 22 décembre 2008 à 09:41. Évalué à 2.
  
  kdirstat est sympa aussi (pour ceux qui utilisent aussi Windows, y a Windirstat, le même pour cet OS).
  Par contre, je me demande comment un programme peut détecter les fichiers encore ouverts mais qui n'ont plus de lien dans le système de fichiers (l'espace ne sera libéré qu'à la fermeture du programme).
  - [^] # Re: filelight et lsof
    
    Posté par wismerhill le 22 décembre 2008 à 20:07. Évalué à 4.
    
    Par contre, je me demande comment un programme peut détecter les fichiers encore ouverts mais qui n'ont plus de lien dans le système de fichiers
    
    En le demandant au noyau.
    C'est exactement ce que fait lsof.
# Tracker le coupable ?

Posté par Ellendhel (site web personnel) le 22 décembre 2008 à 08:36. Évalué à 5.

Il me semble qu'il y a eut plusieurs soucis mentionnés avec Tracker qui construit sa base d'indexation de fichier, qui grossi rapidement (mais qui n'entraîne pas de suppression ou autre).

Au besoin, vérifie les fichiers concernés indiqués sur la page d'aide correspondante sur le site francophone d'Ubuntu : http://doc.ubuntu-fr.org/tracker.
- [^] # Re: Tracker le coupable ?
  
  Posté par tipmeabout le 23 décembre 2008 à 14:20. Évalué à 2.
  
  j'avais eu le problème avec strigi et son index de 15 Go.
  il a pas mis long feu à dégager de chez moi
# Deux choses:

Posté par Ph Husson (site web personnel) le 22 décembre 2008 à 11:05. Évalué à 4.

1.C'est pas forcement étonnant que quand tu supprime tes fichiers l'espace n'est pas libéré: Si un fichier est encore occupé, le fichier existe toujours, il est juste marqué "à éffacer", et ne le sera effectivement que quand il aura fini (donc à relier avec ce qui est dit au dessus si un programme crée un fichier de 4Go meme si tu le supprime il restera)
2.Va sur http://guichaz.free.fr/iotop/ pour avoir un top des accès disques (bon il est très rudimentaire mais ca suffit)
- [^] # Re: Deux choses:
  
  Posté par GTof le 22 décembre 2008 à 14:50. Évalué à 1.
  
  Génial!! Exactement ce qu'il me fallait! Merci beaucoup!
- [^] # Re: Deux choses:
  
  Posté par Étienne le 22 décembre 2008 à 16:41. Évalué à 3.
  
  1.C'est pas forcement étonnant que quand tu supprime tes fichiers l'espace n'est pas libéré: Si un fichier est encore occupé, le fichier existe toujours, il est juste marqué "à éffacer", et ne le sera effectivement que quand il aura fini (donc à relier avec ce qui est dit au dessus si un programme crée un fichier de 4Go meme si tu le supprime il restera)
  
  Pour trouver la liste des fichiers qui sont supprimés mais toujours ouvert, on peut utiliser :
  
  $ find /proc/*/fd -type f -links 0
  
  Cela peut faire apparaitre des erreurs du style "File system loop detected" qu'une redirection de stderr vers /dev/null ferra disparaitre.
  
  On peut même en récupérer le contenu en copiant le fichier vers un autre endroit. Et en prime on a le pid du fichier qui correspond au sous-répertoire de /proc, par exemple
  
  /proc/3594/fd/3 - > /var/run/dhcpcd-br0.pid (deleted) est un fichier supprimé, qui est toujours ouvert par le programme de pid 3594.
  
  Étienne
# find & du

Posté par Lol Zimmerli (site web personnel, Mastodon) le 22 décembre 2008 à 12:11. Évalué à 3.

Avec un habile mélange de find et du dans un petit script lancé 2-3x/jour tu devrais rapidement trouver le coupable.

Genre:
find / -type d -exec du -smh {} \;

Attention, si tu ressors ça sur un fichier, ça va faire un fichier qui grandit rapidement :)
La gelée de coings est une chose à ne pas avaler de travers.
# log

Posté par B16F4RV4RD1N le 22 décembre 2008 à 14:42. Évalué à 2.

fais un :

du -h /var/log

si tu vois que cela fait plusieurs giga, c'est sans doute qu'il y a un problème matériel ou logiciel qui se retrouve transcrit plusieurs fois par secondes dans les journaux (j'ai déjà vu cela, quelques giga en quelques heures). Avec dmesg tu pourras en savoir plus.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Hmmm ...

Posté par LaBienPensanceMaTuer le 22 décembre 2008 à 15:08. Évalué à 3.

J'ai jamais vu ni entendu dire que Ext3 tronquait de sa propre initiative des fichiers sur un systèmes de fichiers pleins ... Ne serait ce pas plutot ton éditeur qui, une fois le fichier chargé, le tronque en vue d'une écriture future ?

Sinon, lorsque j'ai besoin de trouver les fichiers responsables d'un remplissage impromptu, j'utilise la commande du -h -x --max-depth=1 à la base du système de fichiers en question, puis je descend dans l'arborescence en fonction de la sortie de du

Et comme il est dit plus haut, un fichier est effectivement supprimé du disque lorsque plus aucun processus ni accède.
Si par exemple, les logs apache sont les coupables, tu auras donc deux solutions:
1/ couper apache et supprimer le fichier avant de relancer apache.
2/ tronquer le fichier de log (genre echo > fichier).

Attention encore une fois, l'espace occupé par ces fichiers "en instance de disparition" apparaitra dans le df mais pas dans le du.
La commande lsof te permettra toutefois de les retrouver (status deleted).
- [^] # Re: Hmmm ...
  
  Posté par NeoX le 22 décembre 2008 à 17:53. Évalué à 3.
  
  c'est un peu ce que propose kdirstat (sous kde) ou baobab (sous gnome) mais avec un interface graphique.
  
  le plus efficace etant de lancer ces logiciels en tant que root pour pouvoir explorer toutes l'arborescence à partir de /
- [^] # Re: Hmmm ...
  
  Posté par Octabrain le 24 décembre 2008 à 12:20. Évalué à 2.
  
  > J'ai jamais vu ni entendu dire que Ext3 tronquait de sa propre initiative des fichiers sur un systèmes de fichiers pleins
  Et alors il fait quoi à la place ? Il invente de l'espace disque pour écrire le reste du fichier ? S'il te reste 3 octets libres (façon de parler, ça marche en blocs mais peu importe), et que tu veux écrire 6 octets, à partir du 4e octet, les écritures échoueront et ton fichier sera écrit à moitié.
  - [^] # Re: Hmmm ...
    
    Posté par briaeros007 le 24 décembre 2008 à 16:37. Évalué à 2.
    
    dans le cas que tu décris, ce n'est pas le fs qui tronque, mais l'application qui prend pas en compte/gere mal les erreurs!
    - [^] # Re: Hmmm ...
      
      Posté par Octabrain le 25 décembre 2008 à 13:57. Évalué à 2.
      
      Et l'application est censée faire quoi alors ?
      - [^] # Re: Hmmm ...
        
        Posté par briaeros007 le 25 décembre 2008 à 19:14. Évalué à 2.
        
        dépend de l'application,
        Dans tous les cas prévenir l'utilisateur
        Si le fichier n'a aucun intéret en étant incomplet, supprimer le fichier.
        Si le fichier peut présenter un quelconque intéret, au choix (de l'utilisateur ou du dvp) , le laisser tel qu'il est, le supprimer et recréer des données qui tiendrons dans la place, en prévenant l'utilisateur, le supprimer...
      - [^] # Re: Hmmm ...
        
        Posté par LaBienPensanceMaTuer le 25 décembre 2008 à 20:16. Évalué à 3.
        
        C'est simple, renvoyer une erreur !
        En l'occurence, c'est définit comme tel dans le système:
        
        [binarym@neotek]:/usr/include% grep -r ENOSPC *
        asm-generic/errno-base.h:#define ENOSPC 28 /* No space left on device */
        
        Et pour descendre plus bas dans la logique "que dois faire l'appli", et bien controler le code retour de l'appel system write(2) et, voyant la valeur de ce dernier (28) avertir l'utilisateur que l'espace disque est insuffisant pour sauver les modifications.
        Donc l'utilisateur intelligent voyant l'erreur, libérera les 100k nécessaires à la sauvegarde de son fichier et réiterera sa modification ....
        
        [^] # Re: Hmmm ...
        
        Posté par Octabrain le 25 décembre 2008 à 23:19. Évalué à 2.
        
        Ultra-simple en effet, surtout que l'opération d'écriture n'est pas forcément directement initiée par l'utilisateur. Prend l'exemple d'un démon qui tourne en fond, il va demander à l'utilisateur (avec une boite de dialogue pour faire bon effet) de libérer de la place, et il retentera l'écriture quand l'utilisateur aura cliqué OK ?
        
        [^] # Re: Hmmm ...
        
        Posté par briaeros007 le 26 décembre 2008 à 13:37. Évalué à 1.
        
        tu as entendu parler d'un truc qui s'appelle "syslog" ?
        Le démon diras "j'ai plus de place, annulation de la procédure en cours".
        Et l'utilisateur concencieux regardera ses logs et verra "tiens faut que je libére de la place et relance ce processus".
        
        [^] # Re: Hmmm ...
        
        Posté par Octabrain le 26 décembre 2008 à 16:50. Évalué à 2.
        
        > Et l'utilisateur concencieux regardera ses logs et verra "tiens faut que je libére de la place et relance ce processus".
        Oui, il n'a que ça a faire, regarder ses logs, et se dire "tiens faut que je relance le processus".
        Non, en pratique les fichiers seront écrits à moitié, et seule une boite de dialogue pourra prévenir l'utilisateur correctement.
        En plus on s'éloigne du sujet de départ où l'autre faisait son caca nerveux à cause de l'utilisation du mot "tronquer".
        
        [^] # Re: Hmmm ...
        
        Posté par yellowiscool le 27 décembre 2008 à 23:18. Évalué à 3.
        
        Une boite de dialogue sur un serveur, ma veut dire qu'il y a une interface graphique.
        
        À part en ncurses ou autre, ça court pas les rues sous linux.
        
        Moi j'aime bien le mail quand c'est important.
        Envoyé depuis mon lapin.
        
        [^] # Re: Hmmm ...
        
        Posté par Octabrain le 28 décembre 2008 à 01:26. Évalué à 2.
        
        Les démons ne sont pas forcément sur un serveur, par exemple gconfd qui tourne avec ton bureau, et il utilise bien de l'espace disque chez l'utilisateur (donc pas comme un simple dbus, qui est aussi un démon chez l'utilisateur), et il y en a d'autres, on peut aussi penser à un démon d'indexation (bien que là ce soit moins grave car les données peuvent être re-générées automatiquement).
        
        [^] # Re: Hmmm ...
        
        Posté par yellowiscool le 28 décembre 2008 à 12:42. Évalué à 3.
        
        Mais ils sont aussi sur les serveurs.
        
        Puis franchement, quelle horreur ces boites de dialogues à propos d'erreurs incompréhensibles. Souvent, les gens finissent pas les fermer sans même plus les lire.
        Envoyé depuis mon lapin.
        
        [^] # Re: Hmmm ...
        
        Posté par briaeros007 le 29 décembre 2008 à 11:11. Évalué à 1.
        
        Non, en pratique les fichiers seront écrits à moitié, et seule une boite de dialogue pourra prévenir l'utilisateur correctement.
        Tu parlais de daemon -et on a donc répondu dessus-, et maintenant tu parle de "boite de dialogue"....
        a va bien?
        
        Non, en pratique les fichiers seront écrits à moitié
        Non, en pratique un sysadin un tant soit peu compétent à un truc qui lui permet de savoir quel est l'utilisation prise sur chaque disque, pour éviter justement que ça arrive!
        Et regarde "régulièrement" ses logs.
        
        Ensuite que pour le luser ça marche pas, peut être, mais c'est une tout autre question.
        
        En plus on s'éloigne du sujet de départ où l'autre faisait son caca nerveux à cause de l'utilisation du mot "tronquer".
        1°) au contraire j'ai l'impression qu'on est en plein dedans
        2°) le problème c'est pas le mot tronquer, c'est dire que c'est le FS qui jouait sur les fichiers, alors qu'en réalité c'est l'application qui écrit le fichier qui le "tronque" (et ne le supprime pas ou autre).
        
        [^] # Re: Hmmm ...
        
        Posté par Octabrain le 30 décembre 2008 à 13:40. Évalué à 2.
        
        Oui, comme je l'ai précisé au dessus, les démons se trouvent aussi sur le bureau, comme gconfd, kded, beagled, etc. J'arrête maintenant cette discussion stérile, bonne journée.
  - [^] # Re: Hmmm ...
    
    Posté par LaBienPensanceMaTuer le 25 décembre 2008 à 18:58. Évalué à 2.
    
    Mais qu'est ce que tu racontes ??!!
    Connais tu vraiment la définition du mot tronquer ?
    
    Pour information:
    
    tronquer, verbe transitif
    Sens Retrancher quelque chose, effectuer des suppressions. Synonyme raccourcir Anglais to shorten
    
    Donc, j'insiste, jamais Ext3 ne va supprimer de lui meme des données.
    Sache que si tu ajoutes des choses à un fichier de conf via un éditeur, tu ajoutes en réalité des choses au buffer de cet éditeur (mémoire, fichier temporaire).
    Le fichier de configuration n'est modifié que lorsque tu sauvegardes ce dernier.
    Si tu n'as pas d'espace disque à ce moment, tu te feras cordialement envoyer chier et basta.
    
    Mais JAMAIS le système ne supprimera des données écrites de sa propre initiative.
    - [^] # Re: Hmmm ...
      
      Posté par Octabrain le 25 décembre 2008 à 23:21. Évalué à 1.
      
      T'es lourd, il a dit "tronquer", c'est un abus de langage, il voulait dire que son fichier est écrit à moitié.
      - [^] # Re: Hmmm ...
        
        Posté par Ph Husson (site web personnel) le 26 décembre 2008 à 22:16. Évalué à 3.
        
        Je vois pas ce que ca a de lourd..
        Heureusement qu'il en parle parce que sinon j'aurais vraiment cru que ext3 perdait des données (ce qui me choque assez fortement), alors que là c'est juste qu'il ne peut pas les enregistrer ...
        
        [^] # Re: Hmmm ...
        
        Posté par LaBienPensanceMaTuer le 29 décembre 2008 à 16:01. Évalué à 1.
        
        Merci :)
        Plus sérieusement, quand un mot représente à peu près 50% de l'énoncé du problème, il me semble justifier d'insister sur sa réelle signification quand l'emploi en est fantaisiste...
        
        [^] # Re: Hmmm ...
        
        Posté par Octabrain le 30 décembre 2008 à 13:43. Évalué à 1.
        
        Sur les 6 threads (et tous les commentaires qui y répondaient) qui ont démarré du message initial, un seul (le tien) n'a pas compris l'emploi du mot "tronquer". Ce n'est pas une faute, mais l'emploi de ce mot est loin d'être "fantaisiste" comme tu le prétends.
        
        [^] # Re: Hmmm ...
        
        Posté par Ph Husson (site web personnel) le 30 décembre 2008 à 16:43. Évalué à 2.
        
        Y a que ce thread qui parle de "tronquage" les autres c'est plutot en rapport à trouver qui bouffe...
        
        [^] # Re: Hmmm ...
        
        Posté par Octabrain le 30 décembre 2008 à 16:46. Évalué à 1.
        
        Parce que ça ne les a pas choqué. [fini pour ici également]
        
        [^] # Re: Hmmm ...
        
        Posté par Ph Husson (site web personnel) le 31 décembre 2008 à 02:14. Évalué à 2.
        
        Je fais parti de ceux qui ont initié un thread, et franchement dans ton "tronqué" j'avais clairement compris la définition propre et pas ce que t'entends par tronquer, j'en avais pas parlé dans mon thread tout simplement parce que ma réponse était déjà relativement longue et flemme d'en rajouter, et surtout que connaitre le comportement de quelque chose d'aussi compliqué qu'un système de fichier dans des cas d'extreme limite c'est tout sauf évident.

Suivre le flux des commentaires

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