A certains égards, LVM ressemble à un système de fichiers dont les fichiers seraient les volumes logiques : lors de la création d’un LV, LVM lui alloue des blocs (extents) dans les PV du VG, si possible contigus, et on peut lire ou écrire dans un LV comme on lit ou écrit dans un fichier de taille fixe. Les informations sur les extents alloués à un LV sont enregistrées dans les méta-données de LVM présentes dans chaque PV, tout comme les méta-données d’un système de fichiers contiennent les informations sur les fichiers. Bien sûr il y a des différences : pas d’arborescence, et on ne peut pas agrandir un LV en écrivant au-delà de la fin comme on peut le faire avec un fichier.
C’est vraiment le minimum syndical et très loin de ce que permet LVM. Le gestionnaire de disques de Windows XP était en dessous de tout, ne permettant que de créer ou supprimer des partitions.
Une fois de plus merci pour tes éclaircissements PascalHambourg. (Même si il me dépasse “un peu”)
Sais tu si LVM à la capacité de réorganiser aux mieux “ces blocs (extents)” ?
J’imagine qu’il ne sont pas forcément contigus (comme tu le précises), surtout en cas de redimensionnements.
En tout cas, j’ai remarqué que le temps de boot et d’arrêt des mes machines étaient diminués avec LVM.
Peu importe ce qu’il deviendra, cette partition me sert comme secours en cas de problème de démarrage sur l’installation principale que j’utilise au quotidien, et pour faire des tests en dur comme je le fais actuellement avec btrfs (comme j’ai déjà eu des surprises avec des différences entre un test en VM et une installation en dur, maintenant avant d’installer en définitif je teste d’abord dans une VM, puis en dur sur sda9, et finalement l’installation définitive se fait sur sda5).
[quote=“PascalHambourg”]- Si je compare ce nouveau schéma final au schéma initial, je constate que la position de début des partitions Stockage et btrfs-test est modifiée, ce qui implique de déplacer tout leur contenu, contrairement à la modification de la position de fin qui n’est qu’un changement de la taille. La copie de grandes quantités de données (ne contenant pas en RAM) d’une position à une autre d’un même disque n’est pas exactement l’opération la plus rapide à cause des nombreux temps d’accès introduits par les déplacements des têtes de lecture-écriture entre ces deux positions. A mon avis tu auras aussi vite fait de sauvegarder les données sur un autre disque, recréer les partitions et restaurer les données.
Ah ? Windows peut agrandir une partition par la gauche ou avec de l’espace libre non contigu ?
Il peut réduire une partition de plus de la moitié de sa taille initiale ? Il peut créer une partition avec des bouts d’espace libre non contigus ?[/quote]
En quelque sorte tu viens de réponde à ma question à savoir que je ne peux pas faire ce que je veux faire sans corrompre mes données ou casser ma MBR… (déplacement par la gauche, redimensionnement par la gauche, espaces non contigüs…)?
Il est bien impossible de faire quelconque opération par la gauche si je me souviens bien?
J’ai une autre question qui me vient à l’esprit. Je ne sais pas à quoi correspond exactement la partition sda2 mais je suppose qu’elle contient le système d’amorçage?
Au cas où je deciderai de supprimer purement et simplement W$7 (partitions sda1, sda2, sda3) et ne conserver que du Linux sur mon disque, comment devrais-je procéder pour réinstaller GRUB sachant que je serai en BTRFS?
Dois-je dédier une partition boot au début du disque de quelques 500Mo? Ou bien installer GRUB à la racine du volume BTRFS, ou encore installer GRUB dans le subvolume contenant mon système de fichiers Debian?
J’avais une arrière-pensée en posant cette question : si son contenu peut être sacrifié, il n’est pas nécessaire de déplacer et agrandir cette partition, il suffit de la supprimer et de la recréer.
[quote=“GOGI”]En quelque sorte tu viens de réponde à ma question à savoir que je ne peux pas faire ce que je veux faire sans corrompre mes données ou casser ma MBR… (déplacement par la gauche, redimensionnement par la gauche, espaces non contigüs…)?
Il est bien impossible de faire quelconque opération par la gauche si je me souviens bien?[/quote]
On peut agrandir une partition par la gauche ou la déplacer, à condition de déplacer son contenu pour qu’il corresponde à la nouvelle position de début. Gparted et le seul outil que je connais qui permet de le faire. Si on se contente de modifier la position de début sans toucher au contenu, ça va évidemment être la catastrophe puisque les données ne seront plus à l’emplacement de la partition.
Qu’entends-tu par “casser le MBR” ?
Cela peut casser le chargeur d’amorçage s’il utilise les listes de blocs (LILO, GRUB s’il n’est pas “embarqué”). GRUB “embarqué” (boot image dans le MBR et core image dans l’espace entre le MBR et la première partition) ne devrait pas avoir de problème si la numérotation de la partition qui contient /boot/grub ne change pas. De toute façon il faudra le réinstaller si /boot passe de ext4 à btrfs.
Je ne suis pas compétent concernant Windows.
[quote=“GOGI”]Au cas où je deciderai de supprimer purement et simplement W$7 (partitions sda1, sda2, sda3) et ne conserver que du Linux sur mon disque, comment devrais-je procéder pour réinstaller GRUB sachant que je serai en BTRFS?
Dois-je dédier une partition boot au début du disque de quelques 500Mo? Ou bien installer GRUB à la racine du volume BTRFS, ou encore installer GRUB dans le subvolume contenant mon système de fichiers Debian?[/quote]
GRUB sait lire btrfs, mais je ne sais pas comment ça se passe si /boot est dans un sous-volume.
[quote=“PascalHambourg”]
GRUB sait lire btrfs, mais je ne sais pas comment ça se passe si /boot est dans un sous-volume.[/quote]
Si je comprends bien cette page : wiki.debian.org/LVM#A.2Fboot ça n’a pas l’air possible.
Cette page ne parle pas de btrfs. Et en ce qui concerne GRUB et LVM, elle est obsolète : GRUB 2 sait lire LVM et supporte /boot dans un volume logique (qui n’a rien à voir avec un sous-volume btrfs).
Pardon pour mon intervention inutile alors, je retourne bêcher J’avoue avoir lu le fil en diagonal, n’ayant jamais utilisé ni BTRFS ni LVM, j’ai dû décrocher à un moment.
Pour l’obsolescence, j’avais quand même regardé la date de dernière mise à jour de la page : le 5 février dernier. Je suis surpris que ça traîne encore dans le Wiki du coup.
Je me doutais de ton arrière pensée et en effet je ne l’ai pas présenté comme ça mais celle-ci peut être supprimée et recréee après si ça m’arrange pour le partitionnement.
Je ne sais pas ce que tu entends par déplacer son contenu, on peut déplacer ou agrandir une partition par la gauche en déplaçant son contenu durant la même opération avec Gparted? Je vais me pencher dessus pour voir comment ça fonctionne, je n’ai pas utilisé Gparted depuis des lustres.
[quote=“PascalHambourg”]Qu’entends-tu par “casser le MBR” ?
Cela peut casser le chargeur d’amorçage s’il utilise les listes de blocs (LILO, GRUB s’il n’est pas “embarqué”). GRUB “embarqué” (boot image dans le MBR et core image dans l’espace entre le MBR et la première partition) ne devrait pas avoir de problème si la numérotation de la partition qui contient /boot/grub ne change pas. De toute façon il faudra le réinstaller si /boot passe de ext4 à btrfs.[/quote]
Ça date de l’époque où je suis passé à Ubuntu, à l’époque j’étais évidemment un ignorant total
J’avais donc installé Ubuntu en dual-boot avec Windows, le grub dans le MBR, ce qui a donc remplacé le chargeur d’amorçage de W$7 (ne me tiens pas rigueur pour les mots peut-être que je m’exprime mal, je maîtrise pas encore le fonctionnement du MBR). Arrivé un jour j’ai du réinstaller Ubuntu et pour cela j’ai souhaité repartitionner mon disque (par la gauche évidemment… ).
J’ai donc repartitionné et dans cette opération il me semble avoir déplacé la partition contenant W$7 également, par la gauche ; malheur m’en a pris (ça n’a pas dû être la seule bourde mais c’était la plus grave)
Au redémarrage, MBR cassé, aucun accès après le bios, disque non reconnu ou vu comme vide je ne me rapelle plus, enfin impossible de faire quoi que ce soit ; avec l’installateur Ubuntu la ou les partitions existantes étaient vues comme RAW… Bref il me fallait avant de continuer récuperer les anciennes données (eh oui à l’époque je n’avais pas le réflexe de sauvegarder avant de manipuler)…
Bref je me rappelle encore très bien à quel point j’en avais “chié” pour récuperer tout ça, il m’avait fallu passer par plusieurs réparateurs de MBR en même temps car le pc ne voulait rien savoir, mais au final j’ai réussi in-extremis je ne sais moi-même pas comment et j’ai récupéré mon W$ sans perdre de données (une chance de cocu je l’admets).
Depuis…, j’installe systématiquement GRUB sur la partition contenant l’os Linux, et je démarre d’abord avec l’amorceur de W$ (à l’aide de Easybcd installé sur W$) qui m’amène à GRUB ou je choisis la partition que je veux lancer par la suite…
Bien entendu si je décide de virer W$7 définitivement dans le cas présent, son amorceur va dégager aussi mais ce que j’appréhende c’est de retomber dans un cas de figure similaire en re-manipulant une partition par la gauche avant.
[quote=“PascalHambourg”][quote=“GOGI”]Au cas où je deciderai de supprimer purement et simplement W$7 (partitions sda1, sda2, sda3) et ne conserver que du Linux sur mon disque, comment devrais-je procéder pour réinstaller GRUB sachant que je serai en BTRFS?
Dois-je dédier une partition boot au début du disque de quelques 500Mo? Ou bien installer GRUB à la racine du volume BTRFS, ou encore installer GRUB dans le subvolume contenant mon système de fichiers Debian?[/quote]
GRUB sait lire btrfs, mais je ne sais pas comment ça se passe si /boot est dans un sous-volume.[/quote]
GRUB sait lire le btrfs, mais pas os-prober apparement?
Actuellement avec le partitionnement que j’ai, GRUB principal (celui qui me sert à booter soit sur sda5, soit sur sda9) est sur sda5 (ext4), mais son os-prober ne trouve pas le système de fichiers btrfs que je teste sur sda9…
J’ai donc dû recopier la partie “BEGIN- /etc/grub/10-linux” de grub.cfg sur sda9 vers le fichier “40_custom” situé dans /etc/grub.d sur sda5, puis faire un update-grub sur sda5 pour avoir sda9 dans le grub de sda5 (je sais c’est une usine à gaz )
C’est pourquoi je doute si demain j’installe plusieurs OS Linux dans différents subvolumes par exemple, que le GRUB retrouve chacun d’eux, et je pensais le coller dans une partition dédiée au début (500Mo) et formatée en ext4…
M’enfin après reflexion tu me diras que partition séparée ou pas, le résultat sera sans doute le même…?
Moi pareil, mais il me semble bien que lorsqu’on déplace une partition, Gparted déplace son contenu en même temps (ce qui peut être long - si c’est immédiat, alors méfiance). Sinon Gparted devrait au moins prévenir que le déplacement d’une partition va détruire son contenu.
L’ennui est que cela oblige GRUB à s’installer en utilisant les listes de blocs. Et à coup sûr, il sera cassé si la partition est déplacée même avec son contenu.
Si : [mono]os-prober[/mono] me détecte bien une installation de Debian en btrfs, dans un volume LVM sur du RAID pour ne pas lui faciliter la tâche. Mais sans sous-volume.
Par contre il ne veut pas me détecter une installation en ext4 sur du bête RAID 1 sans LVM…
Non, c’est une méthode parmi d’autres. On peut mentionner aussi le chargement du fichier grub.cfg avec la commande [mono]configfile[/mono] si les versions de GRUB sont compatibles ou le chaînage du chargeur avec la commande [mono]chainloader[/mono], qui ont l’avantage de ne pas avoir besoin de mettre à jour le fichier 40_custom en cas de changement dans le fichier grub.cfg originel (installation d’un nouveau noyau, ajout de paramètres du noyau…).
Eh bien il me semble que lors du problème que je t’ai raconté au-dessus, j’avais justement fait le con en croyant être plus malin que Gparted à l’époque et que j’ai ignoré le message… Après j’ai compris
Mais bon ça c’était il y a presque 10ans maintenant, j’imagine que les choses ont évolué depuis (moi aussi j’ai évolué, je fais moins le con entre parentèses )
L’ennui est que cela oblige GRUB à s’installer en utilisant les listes de blocs. Et à coup sûr, il sera cassé si la partition est déplacée même avec son contenu.[/quote]
Ça supposera de faire uniquement un update-grub ou bien de réinstaller? J’imagine réinstaller…
[quote=“PascalHambourg”]
Si : [mono]os-prober[/mono] me détecte bien une installation de Debian en btrfs, dans un volume LVM sur du RAID pour ne pas lui faciliter la tâche. Mais sans sous-volume.
Par contre il ne veut pas me détecter une installation en ext4 sur du bête RAID 1 sans LVM…[/quote]
Ah oui c’est ce que je voulais dire, os-prober pour l’instant ne va pas encore fouiller dans dans les sous-volumes d’un système de fichiers btrfs, si tant est que l’os soit installé dans un sous-volume.
À vrai dire j’ai suivi le tuto de debian-facile pour cette opération car pareil je ne maîtrise pas grub à ce niveau. Je vais me pencher sur ces commandes.
Etant donné que dans mon cas les versions de GRUB sont les même sur sda5 et sda9, comment puis-je faire le chaînage de grub.cfg qui se trouve sur sda9 vers le GRUB installé en sda5 afin qu’il soit mis à jour automatiquement…?
Pour l’instant à chaque fois qu’il y a une modif du grub.cfg de sda9 comme tu dis, je dois faire un update-grub sur sda5 pour que ce soit pris en compte effectivement.
Oui, avec [mono]grub-install[/mono]. [mono]update-grub[/mono] ne fait que regénérer le fichier de configuration grub.cfg.
Ce n’est pas du chaînage. Le chaînage, c’est quand un chargeur lance un autre chargeur.
Et ça ne met rien à jour, ça dit juste au chargeur de lire un autre fichier de configuration, pour afficher un autre menu.
Dans l’entrée de menu insérée dans 40_custom, au lieu des lignes [mono]linux[/mono] et [mono]initrd[/mono], il faut mettre une ligne (ne pas mettre /boot si séparé de la racine)
Sans modifier manuellement 40_custom ?
Note qu’au lieu de 40_custom tu peux utiliser /boot/grub/custom.cfg qui n’est pas inclus statiquement dans grub.cfg par [mono]update-grub[/mono] mais lu à l’exécution de GRUB.
Oui, avec [mono]grub-install[/mono]. [mono]update-grub[/mono] ne fait que regénérer le fichier de configuration grub.cfg.[/quote]
Bien entendu
Ce n’est pas du chaînage. Le chaînage, c’est quand un chargeur lance un autre chargeur.
Et ça ne met rien à jour, ça dit juste au chargeur de lire un autre fichier de configuration, pour afficher un autre menu.
Dans l’entrée de menu insérée dans 40_custom, au lieu des lignes [mono]linux[/mono] et [mono]initrd[/mono], il faut mettre une ligne (ne pas mettre /boot si séparé de la racine)
Merci Pascal pour cette commande. Je l’ai un peu arrangé à ma sauce et ça fonctionne en effet. C’est bête quand même que GRUB ne soit pas capable d’aller chercher ça tout seul lors d’un update-grub…
En gros avec cette ligne je n’ai plus à me soucier de faire un update-grub sur sda à chaque fois qu’il y aura une modification sur le fichier grub.cfg situé sur sda9…?
Sans modifier manuellement 40_custom ?
Note qu’au lieu de 40_custom tu peux utiliser /boot/grub/custom.cfg qui n’est pas inclus statiquement dans grub.cfg par [mono]update-grub[/mono] mais lu à l’exécution de GRUB.[/quote]
Non bien entendu, j’étais obligé à chaque fois que le fichier grub.cfg sur sa9 est modifié, de corriger 40_custom sur sda5, redémarrer, passer en recovery-mode sur sda5, faire un update-grub (tu me diras j’aurai pu le faire en chroot sur sda9) et redémarrer à nouveau.
Par contre je n’ai pas connaissance de custom.cfg, je vais voir ce que c’est.
Exactement. Mais cela ajoute une étape supplémentaire au boot : affichage du premier menu, sélection et affichage du second menu, sélection du noyau.
Regarde dans le script /etc/grub.d/41_custom.[/quote]
Effectivement ça rajoute une étape au boot mais c’est pas grave étant donné que c’est provisoire, et puis je prefère avoir accès au menu du gub installé sur sda9 et accéder à la console en cas de pépin, plutôt que d’avoir à redémarrer sur sda5 et faire un chroot.
En tous cas merci Pascal pour toutes ces infos et conseils encore une fois, tes connaissances sont précieuses, et puis je reviens terminer ce fil dès que j’en aurais fini avec mon pc.
Le deuxième vient de phoronix, un site ou plutôt d’un blog anglophone qui produit des articles et revues sur tout ce qui touche au monde Linux, certains connaissent sans-doute. Cet article pointe vers un autre article qui fait le rapport de benchmarks entre btrfs, lvm(ext4) et md(ext4) sur 14 SSD en montage simple puis en RAID 0 :
