Forum Linux.debian/ubuntu Écart analyse gnome-disk et df -h

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
-1
30
juin
2020

Bonsoir à tous,

J'ai effectué le resize d'une VM avec les commande ci-dessous.

sudo qemu-img info debian_maison.qcow2 && \
sudo qemu-img resize debian_maison.qcow2 +20G && \
sudo cp debian_maison.qcow2 debian_maison_origin.qcow2 && \
sudo virt-resize --expand /dev/sda2 debian_maison_origin.qcow2 debian_maison.qcow2

Depuis, j'ai un écart de 10Go correspondant au resize de ma VM pour l'agrandir.

df -h
202G    188G  3,8G  99% /home

Contre 93,2% sur gnome-disk-utility.

Comment puis-je récupérer cet espace après avoir supprimé la VM en .qcow2 ?

Par fsck ?

Merci

  • # root ou non root

    Posté par  . Évalué à 2 (+0/-0). Dernière modification le 30/06/20 à 20:37.

    Écart analyse gnome-disk et df -h

    au pif, df -h tient compte des 5% du root, alors que gnomedisk, lancé avec ton utilisateur ne peut pas accéder à ces 5% ( ~99% - 5% ~= 93,8% )

    quant aux 10Go "perdus" entre les manipulations
    tu redimensionnes le disque avec qemu-img pour ajouter 20Go puis tu vire-resize

    sudo qemu-img resize debian_maison.qcow2 +20G &&

    puis tu copies/clones ce fichier

    sudo cp debian_maison.qcow2 debian_maison_origin.qcow2 && \

    pour ensuite faire un virt-resize

    sudo virt-resize --expand /dev/sda2 debian_maison_origin.qcow2 debian_maison.qcow2

    mais d'après le manuel tu peux gagner du temps et faire directement l'extension avec virtuel-resize

    sudo cp debian_maison.qcow2 debian_maison_origin.qcow2 && \
    sudo virt-resize --resize /dev/sda2+20Go debian_maison_origin.qcow2 debian_maison.qcow2

    ensuite une fois vérifié que la nouvelle VM fonctionne, il faut évidemment supprimer maison_origin

    • [^] # Re: root ou non root

      Posté par  . Évalué à 1 (+0/-0). Dernière modification le 30/06/20 à 21:36.

      Je n'ai plus le fichier qcow2, il est déjà supprimé !

      quant aux 10Go "perdus" entre les manipulations
      tu redimensionnes le disque avec qemu-img pour ajouter 20Go puis tu vire-resize

      Hein ? j'ajoute 10 Go non ? mais sur /dev/sda5 , …, c'est faisable ?

      gnome-disk-utility (user) -> 
      total 221 Go ; libre 11Go ; utilisation 95,0%
      
      df -H -> 
      total 217G ; utilisé 206G ; libre 0 ; utilisation 100%
      

      => cherche l'erreur, je vois pas comment résoudre ceci !

      • [^] # Re: root ou non root

        Posté par  (site Web personnel) . Évalué à 4 (+2/-0). Dernière modification le 30/06/20 à 21:46.

        Je dirais qu'il y a un bug dans gnome, car df est bien plus "robuste" ;-) Ensuite, il y a aussi de Gio et des Go…

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: root ou non root

          Posté par  . Évalué à 1 (+0/-0). Dernière modification le 30/06/20 à 21:56.

          oui mais alors la ça colle pas bien :

          user@pchome:~$ df -H
          Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
          udev               4,1G       0  4,1G   0% /dev
          tmpfs              822M    9,9M  812M   2% /run
          /dev/sda4           30G     11G   18G  39% /
          tmpfs              4,2G       0  4,2G   0% /dev/shm
          tmpfs              5,3M    4,1k  5,3M   1% /run/lock
          tmpfs              4,2G       0  4,2G   0% /sys/fs/cgroup
          /dev/sda5          217G    202G  4,2G  98% /home
          /dev/sda2          101M     33M   68M  33% /boot/efi
          tmpfs              822M     13k  822M   1% /run/user/1000
          
      • [^] # Re: root ou non root

        Posté par  . Évalué à 2 (+0/-0).

        Hein ? j'ajoute 10 Go non ? mais sur /dev/sda5 , …, c'est faisable ?

        non 20Go d'apres ta ligne :

        qemu-img resize debian_maison.qcow2 +20G

        mais comme c'est du qcow2, il est possible que la taille provisionnée (utilisée) soit plus faible

        sinon les deux outils sont d'accord sur la quantité libre restante, le pourcentage, pour moi est le 5% réserve à root, pris en compte ou non dans le calcul de chaque outil.

        GNOME : Libre 11Go

        DF : Total : 217G - Utilisé : 206G => Libre : 11G

        ensuite ton df -H affiche des gigas en 1000, il faut utiliser -h pour afficher les gigas en base 1024

        man df
        -h, --human-readable
        print sizes in powers of 1024 (e.g., 1023M)
        -H, --si
        print sizes in powers of 1000 (e.g., 1.1G)

        • [^] # Re: root ou non root

          Posté par  . Évalué à 1 (+0/-0).

          GNOME : Libre 11Go
          DF : Total : 217G - Utilisé : 206G => Libre : 11G

          Le souci c'est que le libre 11G que tu indique est 0G pour df -H !

          df -H -> 
          total 217G ; utilisé 206G ; libre 0 ; utilisation 100%
          

          J'ai bien 11Go de bloqué quelque part, mais je vois pas ou !

          • [^] # Re: root ou non root

            Posté par  . Évalué à 3 (+1/-0).

            J'ai bien 11Go de bloqué quelque part, mais je vois pas ou !

            Je repete, il y a 5% d'espace disque RESERVE à l'usage de root

            5% de 220Go = 11Go => 11Go sont réservés à l'utilisateur root
            ils sont donc inutilisables par l'utilisateur, donc ton df ou gnome-disk, vu de l'utilisateur te dit que ton disque est plein

            mais si tu fais la meme commande en tant que root (ou sudo df -h) il devrait te dire que tu utilise 95% de ton disque

            • [^] # Re: root ou non root

              Posté par  . Évalué à 1 (+0/-0).

              Je prends note, voici le résultat des deux commandes,

              Je ne note pas de différence,

              user@pc_portable:~$ df -H
              Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
              udev               4,1G       0  4,1G   0% /dev
              tmpfs              822M     11M  812M   2% /run
              /dev/sda4           30G     11G   18G  39% /
              tmpfs              4,2G     14M  4,1G   1% /dev/shm
              tmpfs              5,3M    4,1k  5,3M   1% /run/lock
              tmpfs              4,2G       0  4,2G   0% /sys/fs/cgroup
              /dev/sda5          217G    202G  4,1G  99% /home
              /dev/sda2          101M     33M   68M  33% /boot/efi
              tmpfs              822M     17k  822M   1% /run/user/1000
              
              root@pc_portable:~# df -H
              Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
              udev               4,1G       0  4,1G   0% /dev
              tmpfs              822M     11M  812M   2% /run
              /dev/sda4           30G     11G   18G  39% /
              tmpfs              4,2G     14M  4,1G   1% /dev/shm
              tmpfs              5,3M    4,1k  5,3M   1% /run/lock
              tmpfs              4,2G       0  4,2G   0% /sys/fs/cgroup
              /dev/sda5          217G    202G  4,1G  99% /home
              /dev/sda2          101M     33M   68M  33% /boot/efi
              tmpfs              822M     17k  822M   1% /run/user/1000
              
              • [^] # Re: root ou non root

                Posté par  . Évalué à 2 (+0/-0).

                ca veut juste dire que df ne fait pas de difference.

                par contre je penses à un truc pour ton fichier effacé, et la recuperation de l'espace.

                tu n'aurais pas oublié de stopper/relancer le service qui utilise le fichier ?

                si c'est le cas, le fichier d'origine est toujours ouvert, meme si c'est le nouveau qui est en usage.

                c'est le cas avec les logs par exemple, le ( r )syslog travaille dans un fichier,
                on n'a plus de place, on efface le fichier sans couper le service, un nouveau fichier est créé, mais on ne voit pas l'espace disque baisser, car le ( r )syslog continue de travailler sur l'ancien.

                il faut relancer le syslog pour que le fichier disparaisse vraiment et qu'on récupère l'espace disque.

                • [^] # Re: root ou non root

                  Posté par  . Évalué à 1 (+0/-0).

                  Est-ce que c'est une solution de faire une image depuis gnome-disk-utility ?

                  Et la redescendre avec le même utilitaire ?


                  Sinon je peux aussi faire la même démarche avec clonezilla

                  • [^] # Re: root ou non root

                    Posté par  . Évalué à 3 (+1/-0).

                    faire une image de quoi, pour faire quoi ?

                    c'est quoi le rapport avec ton espace disque "perdu" ?

                    • [^] # Re: root ou non root

                      Posté par  . Évalué à 1 (+0/-0). Dernière modification le 01/07/20 à 20:59.

                      J'ai enlevé virt-manager et les daemon en relation.

                      Rien n'y fait.

                      Du coup, parfois, de faire une image de la partition /home concerné, ca enlève des problèmes.

                      Peut etre que celui-ci sera résolu avec une tel opération.

                      Avec gnome-disk-utility
                      Ou Clonezilla

                      • [^] # Re: root ou non root

                        Posté par  . Évalué à 2 (+0/-0). Dernière modification le 02/07/20 à 09:28.

                        Du coup, parfois, de faire une image de la partition /home concerné, ca enlève des problèmes.

                        toujours pas compris ce que tu veux faire par là.

                        et ce n'est pas "enlever" virt-manager, mais simplement l'arrêter et le redémarrer (ou redémarrer la machine pour qu'il libère les inondes du precedent qcow2

                        sinon tu avais un fichier qcow2 d'une certaine taille,
                        tu l'as copier en fichier_origin, que tu as fait grossir de 20Go
                        ensuite tu as appliqué le virt-resize dans ce fichier pour agrandir sda2 et remplacer l'ancien qcow2

                        il est donc normal de "perdre" 20Go sur le disque dur de la machine physique puisque le qcow2 a grossi de 20Go,
                        à l'inverse dans la VM (qui utilise le qcow2), tu as du gagné 20Go

Envoyer un commentaire

Suivre le flux des commentaires

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