Forum Linux.général Mais à qui appartient cette partition ?

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
2
21
déc.
2021

Bonjour à tous,

J'ai monté il y a quelques temps un serveur (une VM) pour tester Docker, jusque là tout va bien. Aujourd'hui j'ai voulu lancer un build et là c'est le drame

OSError: [Errno 28] No space left on device

Après analyse il s'avère que docker-compose utilise le répertoire /tmp pour faire les build et pas de bol je l'ai fais trop petit

df -h
Sys. de fichiers                      Taille Utilisé Dispo Uti% Monté sur
udev                                    3,9G       0  3,9G   0% /dev
tmpfs                                   796M    1,3M  795M   1% /run
/dev/mapper/docker01--vg-root         2,1G    1,7G  312M  85% /
tmpfs                                   3,9G       0  3,9G   0% /dev/shm
tmpfs                                   5,0M       0  5,0M   0% /run/lock
/dev/sda1                               470M     85M  361M  19% /boot
/dev/mapper/docker01--vg-tmp          242M     12K  225M   1% /tmp --> trop petit
/dev/mapper/docker01--vg-home         4,9G    3,7G  958M  80% /home
/dev/mapper/docker01--vg-var         1013M    319M  625M  34% /var

C'est du LVM donc en théorie c'est facile, j'agrandis le disque de la VM et je modifie le pv pour prendre en compte la nouvelle capacité. Sauf que je me retrouve avec une configuration bizarre.

Mon pv est stocké sur /dev/sda

    lsblk /dev/sda
    NAME                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    sda                         8:0    0   20G  0 disk 
    ├─sda1                      8:1    0  487M  0 part /boot
    ├─sda2                      8:2    0    1K  0 part 
    ├─sda3                      8:3    0   10G  0 part /export
    └─sda5                      8:5    0  9,5G  0 part 
      ├─docker01--vg-root   254:0    0  2,2G  0 lvm  /
      ├─docker01--vg-var    254:1    0    1G  0 lvm  /var
      ├─docker01--vg-swap_1 254:2    0  976M  0 lvm  [SWAP]
      ├─docker01--vg-tmp    254:3    0  260M  0 lvm  /tmp
      └─docker01--vg-home   254:4    0  5,1G  0 lvm  /home

Le problème est avec sda2, je ne vois pas trop d'où il sort et puis je n'ai pas la même info entre lsblk et fdisk

fdisk -l /dev/sda
Disque /dev/sda : 20 GiB, 21474836480 octets, 41943040 secteurs
Modèle de disque : Virtual disk    
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x4913323d

Périphérique Amorçage    Début      Fin Secteurs Taille Id Type
/dev/sda1    *            2048   999423   997376   487M 83 Linux
/dev/sda2              1001470 20969471 19968002   9,5G  5 Étendue
/dev/sda3             20969472 41943039 20973568    10G 83 Linux
/dev/sda5              1001472 20969471 19968000   9,5G 8e LVM Linux

lsblk m'annonce une taille de 1K alors que fdisk m'annonce une taille à 9.5G… J'ai un doute mais vu les positionnement des secteurs sda5 est dans sda2, c'est ici que s'arrête ma connaissance des partitions avec Linux.

pvdisplay 
  --- Physical volume ---
  PV Name               /dev/sdb1
  VG Name               docker-data
  PV Size               <50,00 GiB / not usable 3,00 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              12799
  Free PE               255
  Allocated PE          12544
  PV UUID               q4Jffx-gH74-I8sS-zy0I-Za6e-r0OJ-sK8dwg

  --- Physical volume ---
  PV Name               /dev/sda5
  VG Name               docker01-vg
  PV Size               9,52 GiB / not usable 0   
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              2437
  Free PE               8
  Allocated PE          2429
  PV UUID               nn6eSu-U9C9-4VfJ-vRao-xmjv-aogI-mIJH4g

Avez-vous une idée ?

  • # hou la ça remonte a loin ;)

    Posté par  . Évalué à 4. Dernière modification le 21 décembre 2021 à 16:19.

    historiquement on ne pouvait avoir que 4 partitions primaires, et pleins de secondaires :) et j'imagine que c'est toujours le cas :D

    les partition sda1,2,3,4 sont les primaires, et les 5+ sont les étendues; les étendues sont contenue dans les primaires, au vue des sorties des commandes je dirais que tes partitions étendues sont dans le sda2 :P

    Généralement la partition étendue est la dernière, mais il n'y a aucune obligation.

    Accessoirement les bios ne démarraient que sur les partitions primaires, depuis uefi j'ai aucune idée si ça a changé.

    C'est un fonctionnement général des disque (c'est pareil sous Windows)

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: hou la ça remonte a loin ;)

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

      Le sujet du partitionnement a toujours été flou pour moi :(

      Je vois un peu prêt la théorie mais j'ai comme l'impression que ma sortie fdisk ne correspond pas

      fdisk -l /dev/sda
      Disque /dev/sda : 20 GiB, 21474836480 octets, 41943040 secteurs
      Modèle de disque : Virtual disk    
      Unités : secteur de 1 × 512 = 512 octets
      Taille de secteur (logique / physique) : 512 octets / 512 octets
      taille d'E/S (minimale / optimale) : 512 octets / 512 octets
      Type d'étiquette de disque : dos
      Identifiant de disque : 0x4913323d
      
      Périphérique Amorçage    Début      Fin Secteurs Taille Id Type
      /dev/sda1    *            2048   999423   997376   487M 83 Linux
      /dev/sda2              1001470 20969471 19968002   9,5G  5 Étendue
      /dev/sda3             20969472 41943039 20973568    10G 83 Linux
      /dev/sda5              1001472 20969471 19968000   9,5G 8e LVM Linux
      

      O_o

      Born to Kill EndUser !

      • [^] # Re: hou la ça remonte a loin ;)

        Posté par  . Évalué à 5.

        C'est exactement ça

        tu as une partition d'amorçage (sda1 de 487 Mo)
        une partition étendue sda2, qui a elle même sa table de partition (avec une seule partition sda5)
        et une 3e partition (sda3 de 10Go)

        c'est pour cela que sda5 est dans sda2, et qu'elle ne commence pas exactement au même secteur, il faut la place pour table de partition de sda2

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: hou la ça remonte a loin ;)

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

          Donc c'est sda2 que je dois agrandir pour pouvoir ensuite agrandir sda5 et le pv ?

          Born to Kill EndUser !

          • [^] # Re: hou la ça remonte a loin ;)

            Posté par  . Évalué à 5.

            Tout à fait, par contre si tu étends sda2, fait bien gaffe à sda3 qui est juste derrière, faut que ton outils gère bien ça.

            Un autre solution serait de créer une partition sda4 et d'utiliser lvm pour ajouter ce qu'il faut; il me semble que c'est tout l’intérêt de lvm, mais j'ai jamais eu à gérer de partition avec lvm, donc je m'avance peut être un peu trop.

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: hou la ça remonte a loin ;)

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

              Merci pour tout ces infos. J'y vois plus clair maintenant.

              En attendant d'avoir le courage de me lancer, j'ai contourner le problème en modifiant la variable TMPFILE avant de lancer le build

              export TMPFILE=/ma/partition/qui/a/grave/de/la/place
              

              Born to Kill EndUser !

              • [^] # Re: hou la ça remonte a loin ;)

                Posté par  . Évalué à 3.

                changer le point de mountage

                tonf fstab doit faire reference à

                /dev/mapper/docker01--vg-tmp

                qui doit etre monté dans /tmp

                si tu supprimes la ligne, le /tmp sera pris dans le /

                si tu crees un dossier dans /ma/partition/qui/a/grave/la/place/tmp
                tu modifies le fichier /etc/fstab pour que ce dossier soit monté en /tmp

                pas besoin de redémarrer la machine, juste démonter/remonter le /tmp

                1°) demonter avant modification du fstab
                2°) modifier le stab
                3°) monter /tmp

              • [^] # Re: hou la ça remonte a loin ;)

                Posté par  (Mastodon) . Évalué à 4.

                C'est une des bonnes manières de faire, me semble t il. À ajouter à Environment de la unit sysd de ton docker.

            • [^] # Re: hou la ça remonte a loin ;)

              Posté par  . Évalué à 2.

              Un autre solution serait de créer une partition sda4 et d'utiliser lvm pour ajouter ce qu'il faut;

              Oui. Voire carrément ajouter un nouveau disque, sans rien toucher à celui déjà présent (ce qui limite le risque de fausse manips, du genre de celles qui ne pardonnent pas quand on touche à une table de partitions).

              Disons que la VM a maintenant un deuxième disque sdb, avec une seule partition sdb1.

              • Faire de sdb1 un nouveau « volume physique » LVM :
              # pvcreate /dev/sdb1
              • Ajouter le nouveau volume physique au groupe de volumes docker01-vg :
              # vgextend docker01-vg /dev/sdb1
              • Augmenter la taille du volume logique docker01-vg-tmp (ici, ajouter 2 GB) :
              # lvextend -L +2G /dev/mapper/docker01-vg-tmp
              • Redimensionner le système de fichiers dans le volume logique pour l’adapter à la taille du volume sous-jacent (ici en supposant que c’est de l’ext4, sinon trouver la commande adaptée au système utilisé est laissé en exercice au lecteur) :
              # umount /tmp
              # resize2fs /dev/mapper/docker01-vg-tmp
              # mount /tmp

              il me semble que c'est tout l’intérêt de lvm.

              « Tout », je ne sais pas, mais c’en est clairement un, oui.

              • [^] # Re: hou la ça remonte a loin ;)

                Posté par  . Évalué à 1.

                Disons que la VM a maintenant un deuxième disque sdb, avec une seule partition sdb1

                Surtout pas malhereux …

                Tu vas faire comment si tu dois étendre le disque ?

                Pas besoin de partitionner le disque, il suffit juste de faire un pvcreate sur /dev/sdb. Le partitionnement sur le disque de boot n'a de raison d'être que pour démarrer la machine.

                • [^] # Re: hou la ça remonte a loin ;)

                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                  Si tu as besoin d'étendre ce sera sdb2 par exemple

                  “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                  • [^] # Re: hou la ça remonte a loin ;)

                    Posté par  . Évalué à 1. Dernière modification le 21 décembre 2021 à 23:06.

                    Crade !!! en plus ça sert à rien. Laisse les choses propores pour ceux qui doivent passer derriere toi STP.

                    • [^] # Re: hou la ça remonte a loin ;)

                      Posté par  (site web personnel, Mastodon) . Évalué à 2.

                      Je trouve justement plus propre d'avoir une partition et qu'elle soit bien marquée comme étant utilisée par du LVM ; ça évite par exemple le cas d'un collègue qui a viré un disque virtuel …parce-que la table de partitions n'existait pas. Bon, ce n'est pas propre à LVM soit dit en passant (j'ai perso failli formater un disque utilisé en mode brut par une base de données propriétaire.)

                      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                    • [^] # Commentaire supprimé

                      Posté par  . Évalué à 5.

                      Ce commentaire a été supprimé par l’équipe de modération.

                      • [^] # Re: hou la ça remonte a loin ;)

                        Posté par  . Évalué à 1.

                        J'ai toujours vu du LVM sur des partitions, non sur les disques eux-mêmes (bien que cela soit possible, on est d'accord).

                        C'est dû a de mauvaises habitudes …

                        Sur des systèmes bien faits (AIX, HP-UX), aucune partition pour les pv que tu ajoutes. Les partitions sur du LVM sous Linux sont pour beaucoup des pratiques d'admin du dimanche qui ne savent pas ce qu'ils font et qui sont en mode pavlov (Disque => Partition => lvm (ou autre chose …).

                        C'est classique (on s'attend à des partitions sur un disque),

                        Pourquoi faire ? A quoi sert une partition sur un disque?

                        Pour moi et (et je pense beaucoup d'administrateurs systèmes), un disque sans partitions (MBR ou GPT) c'est un disque non formaté (et donc non utilisé).

                        Parce que ce sont des admin systèmes qui ont de mauvaises habitudes.

                        • [^] # Commentaire supprimé

                          Posté par  . Évalué à 4.

                          Ce commentaire a été supprimé par l’équipe de modération.

                          • [^] # Re: hou la ça remonte a loin ;)

                            Posté par  . Évalué à 1.

                            multiple physical volumes on a single disk

                            Mais pourquoi faire ça ?

                            Pour moi : 1 PV (physical volmume) = 1 disque.

                            a striped logical volume when two physical volumes are on the same physical disk

                            La encore, pourquoi faire ça ?

                          • [^] # Re: hou la ça remonte a loin ;)

                            Posté par  . Évalué à 2.

                            Si au moins tu étayais pour dire POURQUOI c'est mieux et plus propre.

                            Je te l'ai dit : permet d'augmenter l'espace disque disponible sur un volume. Il est beaucoup plus simpmle de le faire sans partition.

                            J'ai bossé dans des contextes ou l'augmentation d'espace disque ne se faisait pas par ajout de disques mais par augmentation de l'espace alloué à un volume (baies SAN ou VM ). Alors, c'est gentil de vouloir ajouter des partitions, mais pour peu que l'admin du dimanche ait déjà fait ça 4 fois sur des partitions primaires (ce qui m'est déjà arrivé …), t'es emmerdé.

                            Dans le cas ou tu veux changer un disque défectueux, si tu as ajouté tes partitions LVM sur le même disque, tu te retrouves a devoir déplacer les données de plusieurs pvs aui sens LVM plutot que d'un seul. Risque d'oubli, et plus de boulot inutile.

                            Ensuite … il m'est déjà arrivé de voir des trucs amusants : disque physique partagé entre plusieurs VG. Ca c'est pas propre. Si tu dédies un disque à un vg, tu n'est pas censé pouvoir faire ce genre de choses. (la encore essaie de remplacer un disque physique qui est partitionné entre plusieurs VG - j'ai pas eu à le faire mais ça m'aurait gonflé)

                            Une partition, comme son nom l'indique, est un élément qui te permet de découper en partie un disque pour en faire des choses différentes. Je ne comprends pas la logique de "couper en un". La seule raison pour avoir des partitions sur un disque Linux avec du LVM, c'est pour le disque de boot, afin que le hardware puisse lancer le système. En dehors ça ne cause plus de problèmes que de solutions.

                          • [^] # Re: hou la ça remonte a loin ;)

                            Posté par  . Évalué à 3.

                            Aparamment tu n'as pas lu le lien que tu as envoyé …
                            Au début :

                            The underlying physical storage unit of an LVM logical volume is a block device such as a partition or whole disk. To use the device for an LVM logical volume the device must be initialized as a physical volume (PV). Initializing a block device as a physical volume places a label near the start of the device.

                            Et à la fin …

                            Although it is not recommended, there may be specific circumstances when you will need to divide a disk into separate LVM physical volumes. For example, on a system with few disks it may be necessary to move data around partitions when you are migrating an existing system to LVM volumes.

                            Donc :

                            • pas recommandé d'avoir un disque séparé en plusieurs PV. Donc exit la solution de créer une partition lorsqu'on agrandit un disque.

                            • si tu crées une seule partition, tu prend des risques et tu te crées du travail inutile à devoir la retailler. Je ne sais même pas si ça se fait à chaud …

                            Conclusion, pour se faciliter la vie, pas de partition sur les volumes lvm, hormis le disque de boot qui en général contient le disque système et n'est que très rarement agrandi à la volée.

                            Merci pour le lien .. .ça m'évite de faire des recherches.

                            • [^] # Re: hou la ça remonte a loin ;)

                              Posté par  (site web personnel, Mastodon) . Évalué à 3.

                              Aparamment tu n'as pas lu le lien que tu as envoyé …
                              Au début :

                              The underlying physical storage unit of an LVM logical volume is a block device such as a partition or whole disk. To use the device for an LVM logical volume the device must be initialized as a physical volume (PV). Initializing a block device as a physical volume places a label near the start of the device.

                              XD on dit l'un ou l'autre et tu choisis d'ignorer une partie…

                              « The underlying physical storage unit of an LVM logical volume is a block device such as a partition or whole disk. » = L'unité de stockage sous-jacent du volume logique LVM est un périphérique de type bloc tel qu'une partition ou un disque entier : L'un ou l'autre est valable, pas seulement ce que tu veux mettre en avant en occultant l'un des deux.
                              « To use the device for an LVM logical volume the device must be initialized as a physical volume (PV). » = Pour utiliser un périphérique [en fait ce bloc, partition ou disque entier] comme volume logique LVM, ce périphérique doit être initialisé en tant que volume physique (PV) [i.e. pour rendre la partition ou le disque entier utilisable par LVM il faut faire un pvcreate dessus] : La phrase doit rester dans son contexte, qui est la phrase précédente (là comme dans la suite, ils mettent « block device» dans le sens « physical storage unit » i.e. « block device such as a partition or whole disk » et en aucun cas une partie à laquelle ta compréhension veut la restreindre.)

                              pas recommandé d'avoir un disque séparé en plusieurs PV. Donc exit la solution de créer une partition lorsqu'on agrandit un disque.

                              Extrapolation votre honneur. Il est dit que ce n'est pas recommandé mais en aucun cas qu'il ne faut pas créer de partition ! (Ah tu vas probablement me dire que j'ai eu des admins du dimanche comme formateurs chez RH en préparant leurs certifs ? Merci pour eux.)

                              Je ne sais même pas si ça se fait à chaud …

                              C'est faisable à chaud, je le fais depuis pratiquement une dizaine d'années.

                              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                              • [^] # Re: hou la ça remonte a loin ;)

                                Posté par  (site web personnel, Mastodon) . Évalué à 4.

                                [je n'ai pas pu éditer à temps]

                                Extrapolation votre honneur. Il est dit que ce n'est pas recommandé mais en aucun cas qu'il ne faut pas créer de partition !

                                Pire, il est expressément indiqué dans l'extrait du ajouté au message auquel tu réponds «  It is generally recommended that you create a single partition that covers the whole disk to label as an LVM physical volume »
                                Mais bon, tu sais mieux que ces gogos du dimanche.

                                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                                • [^] # Commentaire supprimé

                                  Posté par  . Évalué à 5.

                                  Ce commentaire a été supprimé par l’équipe de modération.

                                  • [^] # Re: hou la ça remonte a loin ;)

                                    Posté par  . Évalué à 1.

                                    Pour ajouter du folklore à cette discussion, ce qui est autrement amusant c'est que redhat recommande de faire des partitions, mais d'un autre côté patche son kernel pour empêcher le resize de partition en live (parce que bon moi aussi j'aime les trucs propres: si je dois agrandir un disque, je préfère agrandir la partition plustôt que d'ajouter un pv) … comprenne qui pourra :D

                                    • [^] # Re: hou la ça remonte a loin ;)

                                      Posté par  (site web personnel, Mastodon) . Évalué à 2.

                                      Excepté la partition / (sur toutes les distributions GNU/Linux d'ailleurs), et encore, je n'ai pas souvenir d'avoir rencontré cette limitation avec du Red Hat. Peut-être une vieille version et/ou un vieux noyaux ?

                                      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                                      • [^] # Re: hou la ça remonte a loin ;)

                                        Posté par  . Évalué à 1.

                                        J'entends bien avec la partition montée. De ce fait ça fonctionne très bien sur / ou sur n'importe quelle autre partition. Seulement redhat a un patch qui verouille la copie kernel de la table des partition si une des partition est "ouverte" (montée ou via un pv lvm), et il me semble que c'était toujours le cas avec une centos 7.

                          • [^] # Re: hou la ça remonte a loin ;)

                            Posté par  . Évalué à 2.

                            Ok, cela en dit long sur le débat. Si on n'est pas d'accord avec toi, c'est qu'on a de mauvaises habitudes.

                            Non c'est un constat issu de 20 années d'expérience en admin système, avec des problèmes à gérer que je n'aurais pas eu si les admins du dimanche savaient ce qu'ils font et pourquoi (après de mon côté, je sais quye certains ont probablement râlé sur certaines habitudes d'admin du dimanche que j'ai pu avoir - et je me suis déjà ralé dessus d'ailleurs parce que certaines de mes mauvaises habitudes m'ont généré des problèmes inutiles).

                            Alors donne moi un (juste un, je ne suis pas gourmand) avantage à utiliser directement le disque au lieu d'une partition.

                            déjà donné : agrandir un disque SAN ou un disque sur une VM.

                            • [^] # Re: hou la ça remonte a loin ;)

                              Posté par  (Mastodon) . Évalué à 5. Dernière modification le 24 décembre 2021 à 10:00.

                              Dans tous les cas on s'en branle que ce soit sur disque ou sur partition.

                              Si tu utilise la partition l'inconvénient c'est que t'as une étape supplémentaire dans le processus si tu étends le lun, tu dois aggrandir la partition avant de faire le pvextend.

                              Mais au final c'est un inconvénient mineur.

                          • [^] # Re: hou la ça remonte a loin ;)

                            Posté par  (Mastodon) . Évalué à 4. Dernière modification le 24 décembre 2021 à 17:49.

                            Parce que c'est casse-figure si on doit réduire.
                            Parce que c'est casse-bonbon lorsqu'on doit outrepasser (cf : la doc que tu pointes)
                            Et aussi parce que .. l'exemple du post ici :-)

                            Enfin, cette doc ne mentionne que des cas déjà dégradés, la doc Red Hat, est comme toujours remarquable de qualité et de conseils.

                            Il me semble que c'est juste une question d'utilisation par défaut. Historiquement il est probable que le cas d'usage le plus courant était que l'installeur, ici anaconda, ne rencontrait qu'un seul disque (que ça soit un disque physique ou un raid) tout simplement. Historiquement aussi, lilo ne savait pas, par défaut, booter sur un lvm (c'était possible, si mes souvenirs sont corrects, mais pas par défaut), ainsi que grub par défaut aussi. Autant de bonnes raisons pour ne pas proposer une conf "pleine LVM" par défaut, et laisser cette configuration aux barbus.

                            Mon avis perso : je panache en fonction du besoin : du "pur et vrai lvm" sur une baie de disques, une install par défaut sur serveur et stations pro, et du pur lvm sur mes serveurs persos, d'autant plus que certains constructeurs recommande maintenant de faire ainsi, parmi les bonnes pratiques dérites, du pur lvm (exemple : les gammes compellent de Dell) pour ne perdre aucune souplesse.

                            • [^] # Re: hou la ça remonte a loin ;)

                              Posté par  (site web personnel, Mastodon) . Évalué à 2.

                              Les outils historiques (comme tu cites : LiLo —et je ne sais pas si ce fut corrigé depuis, mais je doute— GrUB-legacy —il semble qu'il n'était pas possible de corriger cela simplement, sans compter les autres trucs à prendre en compte, d'où la réécriture GrUB2— les installeurs, etc.) ont du mal avec LVM… Mais ça s'est amélioré depuis belle lurette.
                              Pour les installeurs, comme Anaconda et DebianInstaller, le fonctionnement par défaut est le cas simple qui convient aux stations de toutes sortes : il n'y a souvent qu'un seul disque, et quand il y en a deux l'usager va en choisir un et s'attend à ce que ce soit le seul usité. Dans ce cas, quand on demande du LVM, souvent en mode automatique, le plus simple est d'avoir un seul VG fait de plusieurs PV sur ce même disque. (C'est assez simple à migrer —même si ça demande du boulot.) En mode d'installation avancé, ou parfois en partitionnement manuel dans le mode standard, il est possible de faire beaucoup plus (comme avoir autant de PV/VG/LV que de disques, de choisir les nommages etc.) : comme tu dis, c'est laissé aux barbus.
                              Tout à fait d'accord qu'il faut composer avec les besoins et situations …contrairement à certains dogmatismes affichés.

                              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                            • [^] # Commentaire supprimé

                              Posté par  . Évalué à 3.

                              Ce commentaire a été supprimé par l’équipe de modération.

                              • [^] # Re: hou la ça remonte a loin ;)

                                Posté par  . Évalué à 0.

                                Mais pourquoi vouloir réduire ? Il faut comparer ce qui est comparable. Si tu rajoutes un disque à LVM, est-ce que tu vas le réduire ? La réponse est non, car c'est impossible.

                                Bien sûr que si, quand tu fais de la réorganisation de données.

                                Si tu rajoutes une partition qui prend tout le disque, histoire de flagger le disque comme étant un disque LVM, pourquoi vouloir la réduire par la suite ? Il faut comparer des cas d'usages comparables.

                                D'ou l'intéret de ne PAS mettre de lvm sur ton disque.

                                J'ai envie de dire que c'est encore plus casse-bonbon si tu rajoutes directement un disque, puisque tu ne peux pas le réduire, à moins de le changer !

                                Bien sur que si tu peux … man pvresize.

                                Tout à fait. Et grosso modo, pour un cas d'usage classique, elle recommande simplement de créer une seule et unique partition qui prend tout le disque plutôt que d'utiliser directement le disque, afin de pouvoir marquer la partition comme étant une partition utilisée par LVM.

                                On s'en fout de "marqauer le disque" comme tu dis. lsblk est bien plus fiable.

                                • [^] # Commentaire supprimé

                                  Posté par  . Évalué à 5.

                                  Ce commentaire a été supprimé par l’équipe de modération.

                                  • [^] # Re: hou la ça remonte a loin ;)

                                    Posté par  . Évalué à -1. Dernière modification le 31 décembre 2021 à 17:29.

                                    tu ne peux pas le réduire, à moins de le changer !

                                    Bien sur que si tu peux … man pvresize.

                                    Non. Tu redimensionnes ce qui est utilisé par LVM, pas la taille de ton disque/partition sous-jacente.

                                    Dis tu ne serais pas un peu de mauvaise fois là ? Évidemment qu'il faut réduire ton disque où la partition sous-jacente. S'il n'y pas de partition, on gagne une étape. Et sur un noyau redhat, on peut (pouvait?) le faire en live, ce qui n'est (n'était?) pas possible avec une table de partition.

                                    (si ma mémoire ne me fait défaut, sous AIX pvresize réduit la partition tout seul aussi… ce qui fait que les anciennes pages de manuel peuvent porter à confusion).

                                    • [^] # Commentaire supprimé

                                      Posté par  . Évalué à 3.

                                      Ce commentaire a été supprimé par l’équipe de modération.

                                      • [^] # Re: hou la ça remonte a loin ;)

                                        Posté par  . Évalué à -2.

                                        Après, arrête aussi avec redhat. D'une part, parce qu'ils ne sont pas les seuls à distribuer des noyaux linux, et d'autres part, car le redimensionnement reste possible, juste qu'il ne se fait pas à chaud.

                                        Il sont les seuls à avoir cette limitation, désolé. Sur une debian, je peux t'agrandir un fs, un lv, un pv, une partition et un disque à chaud, dans une redhat ou centos ça ne fonctionne pas et cela est du à un patch spécificique de redhat. Je te laisse chercher sur stackoverflow et je t'invite à tester dans une vm si tu ne me crois pas…

                                        On ne peut pas réduire un disque dur. Ca n'a pas de sens.

                                        De la même façon qu'on ne peut pas agrandir un disque dur… Si tu as un SAN, que tu utilise le cloud ou des VM, c'est à dire que si tu paye ou que tu facture ces ressources, ça a du sens. Même s'il apporte quelque facilité en desktop, LVM est plustôt prévu à la base pour une utilisation serveur. Je te rappelle qu'il est issu de la technologie mainframe d'IBM AIX, et de ce fait il a été pensé pour que tout puisse se faire en ligne.

                                        Moi je répondais juste à ta question de savoir

                                        C'est quoi la différence entre avoir le disque tout entier ou avoir la seule et unique partition du disque qui prend toute la capacité du disque

                                        C'est dommage que tu choisisse d'exclure mon seul argument qui découle d'une réelle impossibilité technique. Encore une fois essaye avec une centos, il n'est pas possible d'augmenter une partition, même pas besoin d'avoir un san ou une vm pour tester, tu n'a qu'à prévoir un espace libre après ta partition. Mais bon, comme d'hab avec toi, tu es toujours le premier à donner des leçons à tout le monde, par contre lorsqu'on te met devant des faits, comme par hasard tout devient hors sujet ou rien n'a plus de sens… bizarre comme comportement sur un forum d'échange technique…

                                        • [^] # Commentaire supprimé

                                          Posté par  . Évalué à 4.

                                          Ce commentaire a été supprimé par l’équipe de modération.

                        • [^] # Re: hou la ça remonte a loin ;)

                          Posté par  . Évalué à 3.

                          Pour appuyer mon point de vue :

                          https://www.redhat.com/sysadmin/lvm-vs-partitioning
                          https://unix.stackexchange.com/questions/252353/does-lvm-need-a-partition-table

                          Quand on travaille sur des volumes SAN ou des VMs qui permettent l'extension de disque à chaud, on en vient vite à haïr les partitions sur des disques autre que les disques de démarrage.

                          Après chez soi, chacun fait ce qu'il veut, mais sur des serveurs pro …

                          • [^] # Commentaire supprimé

                            Posté par  . Évalué à 3.

                            Ce commentaire a été supprimé par l’équipe de modération.

                            • [^] # Re: hou la ça remonte a loin ;)

                              Posté par  . Évalué à -1. Dernière modification le 31 décembre 2021 à 17:14.

                              Tes problèmes de redimensionnement, j'avoue ne pas les comprendre.

                              Pourtant c'est simple: en virtuel (ou avec un SAN), cela évite d'avoir une multitude de petits disques, il suffit d'agrandir toujours le même disque et de faire un pvresize.

                              Sur un environnement physique, lorsque la limite des connections est atteinte, tu seras bien obligé de remplacer les plus petit disques (physiques) par des modèles de plus grande capacité. Si tu as du raid, tu remplaces tes disques l'un après l'autre, et tu finis par un pvresize (en live donc).

                              Ne pas avoir de table de partition permet 1: de contourner une limitation des noyaux red-hat 2: d'éviter la phase de changement de la table des partition (et historiquement d'éviter les limitations des tables mbr si on décide de faire resize disque + nouvelle partition) 3: éviter les surprises avec le backup gpt qui se trouve à la fin du disque.

                              • [^] # Re: hou la ça remonte a loin ;)

                                Posté par  . Évalué à -1.

                                Un autre avantage est d'éviter tout problème d'alignement (les lv étant alignés de facto sur 4MB).

                                • [^] # Re: hou la ça remonte a loin ;)

                                  Posté par  . Évalué à 5.

                                  Et le jour ou un on boot le disque sur un autre os, l'autre os va proposer de formater le disque car personne n'a pensé que ce serait une bonne idée de marquer à quoi sert le disque.

                                  Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                  • [^] # Re: hou la ça remonte a loin ;)

                                    Posté par  . Évalué à 0.

                                    Il n'y a que windows pour proposer de formater un disque sans table… Un linux va détecter ton disque comme un membre LVM. Mais si vraiment ton seul problème c'est de pouvoir mettre le disque d'un serveur dans un pc windows sans risquer de perdre des données, alors effectivement il est sans doute plus opportunt d'utiliser des partitions. Cela ne me semble pas être dans le cadre d'une utilisation pro avec un san, des vm ou du raid hw, mais bon c'est sans doute le mieux pour ce cas d'usage original. Les sysadmins qui ont déjà eu des vm redhat à gèrer continueront à mettre un pv sur un disque en entier (ou pas :D)

                                    • [^] # Re: hou la ça remonte a loin ;)

                                      Posté par  (site web personnel, Mastodon) . Évalué à 2.

                                      Ce n'est pas lié spécifiquement à du Windows : j'ai eu le coup avec d'anciennes distributions GNU/Linux (avec du LVM et non LVM2 sur l'un), mais aussi d'autres Unix-like. Bref, ceinture et bretelles quand on a des environnements avec plusieurs systèmes d'exploitations différents.

                                      Même dans le cas d'un parc pro homogène, on n'est pas à l'abri quand il y a plusieurs intervenants ou du turn-over et/ou du micro-management.
                                      Un exemple vu il y a quelques mois : un ticket urgent arrive pour demander d'ajouter de l'espace sur un système de fichiers. Le premier op ajoute un disque virtuel et demande de préciser le FS à étendre. Pas de réponse et il est en congé le lendemain où le ticket est relancé en urgence. Un autre op, prend le relais. OK, mais il a passé du temps à dérouler la pelote (heureusement sinon c'eut été un incident de production majeur) car n'ayant pas su retrouver facilement le nouveau disque (pour le coup il y en avait même deux vides et d'autres n'étaient pas pleinement utilisés non plus…)

                                      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                            • [^] # Re: hou la ça remonte a loin ;)

                              Posté par  . Évalué à 1. Dernière modification le 01 janvier 2022 à 00:22.

                              Pour les SAN ou les VMs, tu réponds encore à côté, car tu opposes LVM au partitionnement. Ce qui n'est absolument pas le sujet ici
                              Ton LVM, que tu lui rajoutes un disque entier ou une partition, ne change strictement rien aux possibilités qu'il offre.

                              Je vais te donner un exemple pour que l'on parle bien de la même chose: tu loues une VM avec disque OS + 1TB de stockage à un client. Le client t'appelle (ou ton monitoring): il manque 100GB. Deux solutions: 1. tu resizes le disque à 1.1TB 2. tu ajoutes un disque de 100GB, ([1]). Les deux fonctionnent, au mois suivant du facture 10% de stockage en plus, tu es content! La différence c'est qu'au 15me appel on va soit se retrouver avec 16 disques, soit avec 1. Hormis l'aspect esthétique et une subtilité technique qui peut être importante (e.g. pour une bdd [2]), il n'y a pas de différence fonctionnelle fondamentale.

                              Par contre si tu choisis de n'avoir qu'un disque avec une table de partition, il te faudra à chaque fois redimensionner la table des partitions (ce qui est à la fois casse-pieds avec les conversion secteurs/KiBi/Kilo, respecter les alignements, etc—il ne faut pas se planter quoi, soit impossible avec redhat - lol). Donc ne pas avoir de table de partition rend la procédure plus simple. On passe de 5 étapes ("rescan scsi bus"-"rewrite partition table"-pvresize-lvresize-growfs) à 4 ("rescan scisi bus"-pvresize-lvresize-growfs), ce qui est plus court et sans l'étape complexe et dangereuse. Ce qui me semble est l'argument de totof2000.

                              Si tu décide d'ajouter un device (ce qui n'est pas toujours possible, i.e. emulation ide ou serveur physique plein), la procédure serait en 5 étapes sans partitions ("rescan scsi"-pvcreate-vgextend-lvresize-growfs), ou bien 6 avec partitions ("rescan scsi"-"create partition"-pvcreate-vgextend-lvresize-growfs), ce qui contient autant d'étapes voire une de plus que précédemment.

                              Donc la question devrait être: pourquoi vouloir utiliser des partitions lorsque cela introduit, au mieux, une étape supplémentaire, ou, au pire, une source d'erreur catastrophique ?

                              La réponse: "je préfère comme ça, je sais pertinemment ou je ne veux pas savoir comment la couche block de linux interagi avec mon SAN et je n'ai jamais utilisé de redhat ni fait d'erreur catastrophique de ma vie" est tout à fait valable hein[3].

                              [1]: On peut aussi ajouter un disque de 1.1TB puis faire un pvremove mais c'est (beaucoup) plus long, ça impacte les perfs, et c'est parfois tout simplement pas possible car on a rarement 110% de capacité en spare.
                              [2]: linux va utiliser 16x plus de queues "virtuelles" sur ton SAN, donc au final il sera très probable que la latence va fortement augmenter.
                              [3]: Perso j'aime bien avoir des partitions, mais je dois reconnaître qu'utiliser des devices directement présente une certaine praticité (et je n'ai pas encore fait d'erreur catastrophique :D).

                              • [^] # Commentaire supprimé

                                Posté par  . Évalué à 3.

                                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: hou la ça remonte a loin ;)

                  Posté par  . Évalué à 2.

                  Tu vas faire comment si tu dois étendre le disque ?

                  Bah je n’étends pas le disque. J’en ajoute un troisième et j’étends le groupe de volumes à la place. :p

                  Désolé, j’ai davantage l’habitude de manipuler des disques bien réels, du genre qu’on ne peut pas étendre à coup de qemu-img resize.

                  il suffit juste de faire un pvcreate sur /dev/sdb

                  J’avoue. Mais j’ai l’habitude de toujours créer une partition, même unique. L’avantage, c’est qu’on contrôle précisément sa taille, ce qui est utile quand on assemble des volumes RAID avec des disques dont les tailles peuvent être légèrement différentes.

                  • [^] # Re: hou la ça remonte a loin ;)

                    Posté par  . Évalué à 1. Dernière modification le 22 décembre 2021 à 10:37.

                    J’avoue. Mais j’ai l’habitude de toujours créer une partition, même unique. L’avantage, c’est qu’on contrôle précisément sa taille, ce qui est utile quand on assemble des volumes RAID avec des disques dont les tailles peuvent être légèrement différentes.

                    Mauvaise habitude. Elle est peut-être utile pour du raid (là je ne vois pas l'intéret dans l'immédiat), mais pour lvm c'est complètement inutile. Dans le cas de VM, ça pousse à faire des manips délicates ou d'avoir un truc crade quand on veut étendre le disque, alors qu'étendre le PV se fait à chaud avec 1 commande (je t'avoue que quand je tombe sur ce cas de figure, je demande un plus gros disque et je déplace les données sur un disque propre, mais ça fait du travail inutile et de la perte de temps pour tout le monde).

                    Désolé, j’ai davantage l’habitude de manipuler des disques bien réels, du genre qu’on ne peut pas étendre à coup de qemu-img resize.

                    La on parle de VM … avec des disques bien souvent de l'ordre de la vingtaine de GB. Et il est souvent avantageux sur ce type de VM d'ajouter de l'espace sur un disque existant que d'ajouter des disques. Après ça nécessite de changer un peu ses habitudes.

                    Ca m'a déjà été utile de procéder comme ça sur un disque physique qui commençait à rendre l'ame : récupération du disque avec ddrescue sur un disque plus gros, et extension du pv via lvm, sans avoir à jouer avec les tables de partition.

    • [^] # Re: hou la ça remonte a loin ;)

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Historiquement, en parlant de ce qui s'est imposé avec le compatible PC, on ne peut avoir que 4 partitions (primaires …et pas plein de secondaires) par disque. Pour faire sauter cette limitation, la partition étendue (une seule sur les quatre, il me semble, les autres ayant alors été baptisées primaires pour différencier) a été créé et elle pouvait comporter plus de partitions (dites logiques du coup.)
      Dans la numérotation Linuxienne (ça peut être différent avec d'autres Unix-like), les chiffres 1 à 4 sont réservés aux partitions primaires/étendue et les 5+ aux partitions logiques qui sont dans la partition étendue. (Juste le vocabulaire sinon on est d'accords.)

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: hou la ça remonte a loin ;)

        Posté par  . Évalué à 2.

        la partition étendue (une seule sur les quatre, il me semble […])

        Chacune des 4 peut être une partition étendue et il peut y en avoir plusieurs (même sous DOS, par contre DOS ne peut booter que sur une primaire). Dans chaque partition étendue, il peut y avoir une infinité de partitions.

  • # disque virtuel + resize2fs

    Posté par  . Évalué à 3.

    en environnement virtualisé, il semble bien plus pratique par expérience de monter autant de disques que nécessaire et de les gérer comme une partition ou un volume disque et sans les partitionner.

    Le disque virtuel est monté directement sans partition ; ex :

    # lister des disque
    fdisk -l 
    
    # formater le disque
    mkfs.ext4 /dev/sdX
    
    # et monter:
    mount /dev/sdX /mnt
    
    
    # retailler:
    # une fois agrandi le disque via le système de virtualisation 
    resize2fs /dev/sdX
    
    # and voila.
    

    cette technique évite totalement de manipuler les partions avec fdisk. Cependant, cela ne fonctionne qu'avec des disques virtuels via un système de virtualisation.

  • # /tmp est petit et c'est bien

    Posté par  . Évalué à 1.

    il s'avère que docker-compose utilise le répertoire /tmp pour faire les build et pas de bol je l'ai fais trop petit

    Le /tmp n'a pas spécialement à être grand ! C'est surtout docker-compose qui fait l'erreur d'utiliser ce répertoire au contenu volatil pour y faire une opération longue et complexe. Le /tmp ne devrait contenir que des petits fichiers temporaires.

    (docker-compose n'est pas le seul, blender, par exemple, met ses sauvegardes automatiques dedans aussi, ce qui fait très vite plusieurs Gio).

Suivre le flux des commentaires

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