D’accord un peu comme LVM mais dans une partition.
C’est un peu le fonctionnent que j’imaginais avant test de LVM, c’est à dire de créer des volumes dans une partition sans système de fichier.
[quote=“cedric058”]D’accord un peu comme LVM mais dans une partition.
C’est un peu le fonctionnent que j’imaginais avant test de LVM, c’est à dire de créer des volumes dans une partition sans système de fichier.[/quote]
Oui et non, enfin je dirais que ce ne n’est ni ça ni l’inverse, en réalité ici tu crée des volumes ou plutôt sous-volumes au sein d’une partition avec système de fichiers (en l’occurence btrfs).
Alors qu’en LVM ou dans une partition étendue, tu crée des volumes logiques dans un groupe de volumes (qui lui est sans système de fichiers), que tu vas formatter par la suite.
Avec LVM, je n’ai jamais rencontré de problèmes, donc je ne m’en suis jamais trop soucié, mais d’après ce que j’ai pu lire “on ne sait pas trop où sont localisés les données”.
Je les localises grossièrement dans le restant du disque qui n’est pas partitionné.
Comme on peut redimensionner à tout vas, ça peut laisser “perplexe”, mais bon si la gestion est bien conçu…
[quote=“GOGI”]Il s’agit donc de restructurer cette table des partitions, avec la migration de l’installation en btrfs se trouvant actuellement sur /sda9 vers la future partition sda5 (en ce qui concerne la fusion je me suis mal exprimé, les données actuelles sur sda5 et sda7 seront supprimées au formatage) à l’aide d’un formattage en btrfs, création des subvolumes puis transfert de snapshots effectués sur /sda9 vers les subvolumes crées sur /sda5.
Dans ce but, j’aimerais donc ramener ces partitions au schéma ci-dessus :[/quote]
- Que devient le contenu de btrfs-test après son transfert vers Root ?
- 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 ?
La fragmentation n’est pas un mal absolu. Ce qui compte, c’est la comparaison entre la granularité (la taille des fragments) et le produit temps d’accèsdébit du disque (qui représente le volume qu’on aurait pu lire ou écrire pendant le temps moyen d’un saut entre deux fragments). Si la granularité est inférieure au produit TAD, alors le disque passe plus de temps à sauter d’un fragment à un autre qu’à lire ou écrire (cas défavorable). Si au contraire la granularité est très supérieure au produit TA*D, alors l’effet de la fragmentation est négligeable (cas favorable).
Application numérique :
Taille par défaut d’un “extent” (fragment) LVM2 = 4 Mio.
Ordre de grandeur du produit temps d’accès*débit d’un disque dur = 10 ms * 100 Mo/s = 1 Mo.
On est donc plutôt dans le cas favorable.
L’expression “sous-volume” peut être trompeuse car elle désigne en fait une racine et un arbre secondaire au sein d’un même système de fichiers, et pas du tout d’un “volume” au sens d’un bloc de stockage comme peut l’être un disque, une partition ou un volume logique.
Euh, une partition étendue n’a rien à voir avec LVM et une partition logique n’a rien à voir avec un volume logique LVM. Elle a les mêmes inconvénients qu’une partition de base, plus des inconvénients propres.
Je n’ai pas poussé le test très loin. Je les essayes juste “très grossièrement” pour me tenir “très grossièrement au courant” et voir si le peu que je produits est compatible.
J’ai simplement redimensionné (par la droite) une partition principale (qui ne contenait que le système) (très rapidement et simplement “comme avec LVM”), je n’ai pas pu bouger la partition de sauvegarde (en fin de disque). Plus rien à voir avec XP qui lui aussi avait un système de fichier NTFS.
Merci pour tes précisions sur la fragmentation PascalHambourg.
Je suppose que LVM doit tenir une sorte de journal pour repérer les emplacements (si ils sont définis à l’avance) des volumes logiques.
Comme on formate un volume logique (vl) à l’avance, les emplacements sont probablement définis à l’avance (réservés).
Encore que:
$ ps aux | grep ext
...ext4-rsv-conver...
Peut être que LVM ne défini pas les emplacements des volumes logiques à l’avance ?
Les données ne sont peut être pas “cloisonnées dans un espace” comme c’est le cas pour les partitions.
Dans ce cas on pourrait trouver “physiquement sur un disque” par exemple, une donnée d’un vl1, puis une donnée d’un vl2, puis une donnée d’un vl1.
[mono]Edit:[/mono] http://lea-linux.org/documentations/Leapro-pro_sys-lvm
Un volume logique LVM semble être “une somme d’espace de 4Mo” “cloisonnées dans l’espace” du groupe de volume.
Un lien sur BTRFS pour ceux que ça intéresse : http://debian-facile.org/doc:systeme:btrfs
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.
LVM offre la possibilité de déplacer des extents avec la commande [mono]pvmove[/mono], mais ça a l’air assez compliqué.
Sinon, je viens aussi de trouver ça, la commande [mono]reorgvg[/mono]:
https://www-01.ibm.com/support/knowledgecenter/ssw_aix_61/com.ibm.aix.performance/reorg_log_vols.htm
Mais un [mono]man reorgvg[/mono] ne donne rien, peut être un paquet à installer ?
Il existe différentes implémentation de LVM pour différents systèmes. La page que tu pointes concerne le système AIX d’IBM, pas Linux.
D’accord, peut être dans le futur alors… 
Merci encore.
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…).