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 fearan . É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 Philippe M (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
O_o
Born to Kill EndUser !
[^] # Re: hou la ça remonte a loin ;)
Posté par fearan . É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 Philippe M (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 fearan . É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 Philippe M (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
Born to Kill EndUser !
[^] # Re: hou la ça remonte a loin ;)
Posté par NeoX . Évalué à 3.
changer le point de mountage
tonf fstab doit faire reference à
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 bubar🦥 (site web personnel) . É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 gouttegd (site web personnel) . Évalué à 2.
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 partitionsdb1.sdb1un nouveau « volume physique » LVM :docker01-vg:docker01-vg-tmp(ici, ajouter 2 GB) :« Tout », je ne sais pas, mais c’en est clairement un, oui.
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . Évalué à 1.
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 Gil Cot ✔ (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 totof2000 . É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 Gil Cot ✔ (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 Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . Évalué à 1.
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 …).
Pourquoi faire ? A quoi sert une partition sur un disque?
Parce que ce sont des admin systèmes qui ont de mauvaises habitudes.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . Évalué à 1.
Mais pourquoi faire ça ?
Pour moi : 1 PV (physical volmume) = 1 disque.
La encore, pourquoi faire ça ?
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . Évalué à 2.
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 totof2000 . É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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
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
pvcreatedessus] : 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.)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.)
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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
[je n'ai pas pu éditer à temps]
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 Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: hou la ça remonte a loin ;)
Posté par benja . É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 Gil Cot ✔ (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 benja . É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 totof2000 . Évalué à 2.
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).
déjà donné : agrandir un disque SAN ou un disque sur une VM.
[^] # Re: hou la ça remonte a loin ;)
Posté par Psychofox (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 benja . Évalué à 0.
Sauf que ça ne marche pas sur redhat…
[^] # Re: hou la ça remonte a loin ;)
Posté par bubar🦥 (site web personnel) . É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 Gil Cot ✔ (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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . Évalué à 0.
Bien sûr que si, quand tu fais de la réorganisation de données.
D'ou l'intéret de ne PAS mettre de lvm sur ton disque.
Bien sur que si tu peux … man pvresize.
On s'en fout de "marqauer le disque" comme tu dis. lsblk est bien plus fiable.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: hou la ça remonte a loin ;)
Posté par benja . Évalué à -1. Dernière modification le 31 décembre 2021 à 17:29.
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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: hou la ça remonte a loin ;)
Posté par benja . Évalué à -2.
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…
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 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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . É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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: hou la ça remonte a loin ;)
Posté par benja . Évalué à -1. Dernière modification le 31 décembre 2021 à 17:14.
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 benja . É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 fearan . É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 benja . É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 Gil Cot ✔ (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 benja . Évalué à 1. Dernière modification le 01 janvier 2022 à 00:22.
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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: hou la ça remonte a loin ;)
Posté par gouttegd (site web personnel) . Évalué à 2.
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.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 totof2000 . Évalué à 1. Dernière modification le 22 décembre 2021 à 10:37.
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).
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 Gil Cot ✔ (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 benja . Évalué à 2.
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.
[^] # Re: hou la ça remonte a loin ;)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
OK, bon à savoir (qu'elles peuvent toutes être étendues)
:-)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# disque virtuel + resize2fs
Posté par Marc Quinton . É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 :
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 cg . Évalué à 1.
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.