Forum général.général Lvm et taille des partitions

Posté par  (site web personnel) .
Étiquettes :
0
3
avr.
2007
Salut tout le monde. Je rencontre un petit problème avec la gestion de mes disques en LVM. Je possède 2 disques scsi 146 Go et 2 disques scsi 73 Go. Chacun étant montés en RAID 1. Sur le disque de 146 je stocks les éléments utilisateurs et les sauvegardes. Malheureusement le volume de données a littéralement explosé en 3 mois. En voulant regarder ce qu'il me restait comme espace je suis tombé sur quelques chose de bizarre.

Résulat de df 
Sys. de fich.        1K-blocs       Occupé Disponible Capacité Monté sur

/dev/mapper/GpVolSys-Lv_root

                      20158332   6617768  12516564  35% /

/dev/mapper/GpVolUser-Lv_backup

                      97148628  86597052   5616716  94% /backup

/dev/sda3               101105     32379     63505  34% /boot

none                   1037408         0   1037408   0% /dev/shm

/dev/mapper/GpVolUser-Lv_home

                      40316280  32257128   6011152  85% /home

/dev/mapper/GpVolSys-Lv_tmp

                       2031952     35896   1892840   2% /tmp

/dev/mapper/GpVolSys-Lv_var

                       5063712    514364   4292120  11% /var

La ligne qui m'inquiète particulièrement c'est celle concernant /backup. df m'annonce que ma partition fait ~98 G que j'ai ~87G d'occupé et qu'il me reste ~5,6 G. Si je calcul avec les vrai valeurs je tombe sur 86597052 + 5616716 = 92213768 hors je suis loin des 97148628 que doit faire ma partition (!) Ma question est, mais où sont passé 4934860 restant ? (non pas ici ;) )

Résultat de vgdisplay
  --- Volume group ---

  VG Name               GpVolUser

  System ID

  Format                lvm2

  Metadata Areas        1

  Metadata Sequence No  5

  VG Access             read/write

  VG Status             resizable

  MAX LV                0

  Cur LV                2

  Open LV               2

  Max PV                0

  Cur PV                1

  Act PV                1

  VG Size               136,59 GB

  PE Size               32,00 MB

  Total PE              4371

  Alloc PE / Size       4262 / 133,19 GB

  Free  PE / Size       109 / 3,41 GB

  VG UUID               pt8L4w-Kg0B-Hb11-JqcP-WBTb-weO9-qnhUE4


Mon disque est annoncé à 136,59 GB formaté en ext3, hors il fait 146 Go, je sais qu'il y a une perte au formatage mais 10 G ça m'étonne. J'obtient le même résultat avec pvdisplay. D'après le vgdisplay il me reste 3,41 non alloué (?) pourquoi pas j'ai pas souvenir avoir gardé une réserve surtout aussi petite.
Ce que je ne m'explique pas c'est la perte de 10Go et l'écart sur le volume Lv_backup.

Est-ce que vous avez une idée ?

  • # Histoire de calcul

    Posté par  . Évalué à 5.

    Déjà, ton disque fait 146 milliards d'octets. Soit, en unité "classique" :
    146*1e9/1024/1024/1024 = 135.97309589385986 Go
    (bizarre, je trouve même moins que ce que t'indiques vgdisplay ...)
    Ça, ça n'est pas une histoire de formatage, juste une histoire d'affichage pas clair de la part des constructeurs (c'est devenu une coutume aujourd'hui).

    Ensuite, pour la partition qui dispose de moins que prévu : _ça_, c'est une histoire de formatage. Ça dépend un peu du type de FS que t'as dessus, mais tous doivent consommer une partie de l'espace afin de conserver toutes les méta-données du système de fichier (le header, l'arbre des fichiers et des blocs alloués, etc ...), et généralement, plus ton FS est gros, plus ces méta-données le sont aussi. En plus, il me semble que les FS gardent un peu d'espace "au cas où", pour éviter de trop saturer le disque, afin de ne pas se retrouver à avoir _vraiment_ 0 blocs disponibles (je me suis déjà retrouvé à 0 blocs libres, et même après avoir supprimé quelques fichiers, j'étais toujours à 0 !). Et ce nombre de blocs réservés doit aussi augmenter avec la taille du FS. Et donc, toutes ces choses font parties de l'espace "total" indiqué par df, mais ne sont pas comptabilisées comme espace "occupé" (je crois, ou peut-être une partie seulement, car il me semble qu'un FS vierge est toujours indiqué comme consommant quelques blocs par df), et sont bien sur enlevées de l'espace "disponible", d'où les différences de calcul.

    Par contre, effectivement, dès que tes partitions sont grosses, ça commence à faire pas mal de place "perdue" (mais de toutes façons, indispensable au FS).

    • [^] # Re: Histoire de calcul

      Posté par  (site web personnel) . Évalué à 1.

      Merci pour ta réponse ultra précise et clair. Donc c'est tout à fait normal comme résultat et je ne vais pas avoir le bonheur de retrouver les quelques giga qui me manque pour mes sauvegardes et je n'ai pas le choix il va falloir acheter deux disques (raid 1) :( C'est mon patron qui va pas être content :D.

      Merci encore pour toute ces informations.

      Born to Kill EndUser !

      • [^] # Re: Histoire de calcul

        Posté par  . Évalué à 2.

        J'ai oublié, mais tu as quand un même un petit bout de récupérable : les 3,41Go de Physical Extent non utilisés : tu pourrais gagner un petit peu sur tes partitions surchargées.

      • [^] # Re: Histoire de calcul

        Posté par  . Évalué à 3.

        man tune2fs
        -m reserved-blocks-percentage
        Set the percentage of reserved filesystem blocks.
        ou
        -r reserved-blocks-count
        Set the number of reserved filesystem blocks.

        Je pense que ce paramètre est positionné, par défaut, à 5% par mkfs.ext[23]. C'est clair que sur de gros disque, c'est beaucoup trop. Normalement, seul root peut utiliser cet espace réservé.

        • [^] # Re: Histoire de calcul

          Posté par  (site web personnel) . Évalué à 1.

          C'est pas mal de pouvoir le paramétré, mais quelles sont les risques ? Parce qu'il doit bien en avoir :(

          Born to Kill EndUser !

          • [^] # Re: Histoire de calcul

            Posté par  . Évalué à 2.

            Je ne pense pas qu'il y ait énormément de risque, à part peut-être dans des cas particuliers.
            J'avais déjà remarqué qu'avec un FS (vraiment) plein, le système se met à ramer parce qu'il n'arrête pas de bouger des blocs dans tous les sens pour trouver un peu d'espace vide. Le pire cas serait celui ou ton OS a absolument besoin d'espace pour effectuer une opération, mais que cette opération soit impossible car le FS ne trouve rien, ou du moins met beaucoup de temps à trouver (ce qui, en général, va rallonger la file d'attente des I/O sur ton disque, et donc demander encore plus d'opérations de ton OS par la suite). J'avais eu une sorte de plantage comme ça, où je ne comprenais pas vraiment pourquoi mon système partait à 100%.
            Le tout, c'est de s'en rendre compte avant, quand un compte autre que celui du superuser commence à se prendre des "filesystem full". Le danger c'est juste de ne pas les voir arriver, et de tomber sur un "filesystem _really_ full" pour l'OS.

            • [^] # Re: Histoire de calcul

              Posté par  . Évalué à 1.

              à ma connaissance le % reservé c'est surtout reservé à root.

              ca te permettrais, si ton systeme ne fonctionne plus, de pouvoir quand meme te logger en root et de faire un peu de menage, d'ouvrir quelques fichiers temporaires...

          • [^] # Re: Histoire de calcul

            Posté par  . Évalué à 3.

            En fait, c'est prévu pour qu'en cas de fs plein (pour un utilisateur), root aie encore une marge de manoeuvre pour réparer les dégats (avec comme effet secondaire la non-impactation immédiate des services qui tournent en root).

            Le danger d'un disque plein c'est d'avoir une application critique se prendre une erreure du noyau lorsqu'elle doit écrire sur le disque. Par exemple une mise-à-jour du système qui foire à cause de cas. Jusqu'à présent, dpkg a toujours bien gèrer cette situation chez moi mais il ne faut pas trop compter sur le fait que l'application aie prévue ce cas de figure (car cet un problème qui peut devenir très complexe en fonction des application et je ne pense pas que linux offre toutes les fonctionnalité nécessaire à la prévention de ce genre d'erreures).

            Note que modifier ce paramètre a juste l'effet de retarder la pleinitude du disque pour les applications lancées par un utilisateur, le risque de perdre des donnée est sans doutes plus important avec les applications utilisateurs (mal codées) qui n'arrivent plus a enregistrer leur état. Dans cette optique là (pour un /home par ex), on peut dire qu'il est plus sûr de baisser (voir de positionner à zéro) ce paramètre puisqu'il retarde la pleinitude du disque. Par contre, pour le / il est important que laisser ce paramètre à une valeur raisonnable, pour qu'un processus qui remplis le /tmp (s'il est sur la même partition) ne puisse pas affecter les services système.

            En pratique, si tu fais attention, tu peux sans problème mettre ce paramètre à zéro. La vm du noyau arrivant plus ou moins bien à différer les écritures arrivant sur un disque plein en attendant qu'il se vide. D'ailleurs, je connais pas d'autre fs qui ont une option comparable. Les quotas et/ou la séparation des /tmp, /home et /var sur une autre partition que / sont quand même bien mieux adaptés pour se protéger contre ce genre de mésaventures.

  • # Octet constructeur ?

    Posté par  (site web personnel) . Évalué à 0.

    L'unité de mesure constructeur est 1ko = 1000 o alors qu'en informatique c'est 1ko = 1024o

    146 Go constructeur =
    146 * 1000 * 1000 * 1000 octets
    pour retrouver ca en octet "informatique" / 1024 / 1024 / 1024

Suivre le flux des commentaires

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