Bonjour à tous,
Voilà la question est plus ou moins dans le titre : à savoir s’il y a un intérêt d’employer les deux pour l’installation d’un système où non? Je pose la question car je ne trouve pas de réponse complète sur internet directement, uniquement des petits bouts par-ci par-là, alors certains disent que le deux sont complémentaires, d’autres qu’il est maintenant superflu d’utiliser LVM avec BTRFS…
Je voudrais surtout avoir une réponse un peu plus concrète… 
A mon avis ils restent complémentaires.
Btrfs n’est qu’un système de fichiers, alors qu’un volume logique LVM peut contenir n’importe quoi d’autre (swap, volume chiffré, autre système de fichiers…).
La capacité de redimensionnement à chaud de btrfs (agrandissement et réduction) est plus facile à mettre en oeuvre si le système de fichiers est dans un volume logique qui a la même capacité que dans une partition simple.
Salut Pascal,
[quote=“PascalHambourg”]A mon avis ils restent complémentaires.
Btrfs n’est qu’un système de fichiers, alors qu’un volume logique LVM peut contenir n’importe quoi d’autre (swap, volume chiffré, autre système de fichiers…).
La capacité de redimensionnement à chaud de btrfs (agrandissement et réduction) est plus facile à mettre en oeuvre si le système de fichiers est dans un volume logique qui a la même capacité que dans une partition simple.[/quote]
En fait tout dépend de l’usage que l’on veut en faire si je comprends bien…? En réalité rien ne nous empêche de créer un partition swap et une pour le btrfs sur un disque donné mais bon apparemment le btrfs ne gère pas swap. Pour le moment btrfs ne gère pas non plus le cryptage en natif (il faut passer par dm-crypt si je ne me trompe pas) mais ca devrait être prévu dans le futur j’imagine.
Si on n’a besoin que de deux partitions par exemple (un ou plusieurs OS/Linux uniquement), une pour le système l’autre pour le swap, on peut se contenter de btrfs et travailler en subvolumes uniquement (ex : partiton btrfs avec un subvolume par OS/Linux avec l’arborescence qui convient)?
Sinon il vaudrait mieux passer avec le couple LVM-btrfs en cas de dual ou triple boot (en particulier avec WS), ne serait que pour bénéficier du redimensionnement des partitions aisé?
D’ailleurs en cas de dual-boot Windows/Linux, j’ai pas encore fait le test si W$ gère le btrfs avec “Ext2fsd” ou pas encore, et inversement si un OS installé sur du btrfs gère parfaitement du ntfs, en gros si c’est bidirectionnel.
Mais la question que je me pose aussi c’est de savoir comment ça se passe lorsqu’on “grille” un OS installé dans un subvolume sur la partition btrfs, au cas où l’on travaille uniquement avec des subvolumes?
Par exemple jusqu’à présent on faisait plusieurs partitions primaires ou logiques sur lesquelles on répartissait le système (racine, home, …) pour éviter d’avoir tout à réinstaller en cas de très gros pépin, et on réinstalle uniquement sur la partition où se trouve “/”. Est-ce qu’avec les subvolumes c’est aussi souple de réinstaller sans perdre sa configuration… (je ne parle pas des snapshots, je pense à une vraie réinstallation dans le subvolume).
Je suis incapable de te répondre sur les subvolumes, n’ayant pas encore exploré cette fonctionnalité néanmoins fort séduisante de btrfs. Mais je pense que j’hésiterais à partager des subvolumes d’un même système de fichiers btrfs entre plusieurs OS, ne serait-ce que pour éviter les effets de bord ou grosses catastrophes. Déjà que partager le même VG LVM, je trouve ça limite…
WS ? Si tu veux parler de Windows, l’ennui est qu’il ne supporte pas LVM, donc la facilité de redimensionnement ne le concernera pas lui et ses partitions. L’utilisation de LVM et/ou btrfs peut quand même avoir comme avantage de limiter le nombre de partitions nécessaires, dans le but d’éviter le recours aux partitions logiques dans le cas où Windows est amorcé en mode BIOS et exige une table de partition au format MSDOS. (Une autre possibilité, c’est la table de partition hybride GPT+MSDOS, ça marche mais dans le genre bancal c’est pas mal aussi.)
En réalité pour l’instant je fais des tests avec btrfs sous une VM avec virtualbox pour apprendre à maîtriser celui-ci. Et j’ai suivi ce tuto : https://debian-facile.org/doc:systeme:btrfs-root-install-subvol qui montre comment installer debian dans un subvolume et profiter des snapshots (car apparemment installer l’OS à la racine du btrfs ne permer pas les snapshots). Bon le tuto est un peu bancal, chez moi ça ne marche pas très bien car il faut faire quelques bricoles pour arriver à booter après l’installation mais rien à voir avec btrfs (fichier fstab vide par exemple).
Et c’est de là que j’ai eu l’idée de gérer plusieurs OS (Linux uniquement évidemment) au travers des subvolumes puisque GRUB sait maintenant gérer le btrfs, le tout sur une partition unique avec en prime la possibilité d’utiliser les snapshots, selon le schéma suivant :
"Racine btrfs" /
"dossier OS1" |_____ OS1
"racine OS1" | |____ Root
"home OS1" | |____ Home
"autres dossiers OS1" | |____ ...
... |
|
"dossier OS2" |_____ OS2
"racine OS2" | |____ Root
"home OS2" | |____ Home
"autres dossiers OS2" | |____ ...
|
|_____ OS...
| |____ Root
| |____ Home
| |____ ...
|
Eventuellement un subvol "Data" |_____ Data
| |____ ...
.
.
.
Le tout bien orchestré et adressé dans chaque fstab respectif, peut-être que ça devrait pas poser de problèmes, étant donné que tout est vu de toute façon comme fichier… (enfin je verrai dans la VM, ça peut être intéressant à expérimenter)? Par contre c’est là qu’intervient ma question de la réinstallation de l’un des OS en cas de très gros pépin : ça devrait marcher en principe à condition de ne pas oublier de bien monter manuellement dans le dossier /target de l’installateur le subvolume correspondant sinon il installe à la racine du système de fichiers et là on perd tout…
WS ? Si tu veux parler de Windows, l’ennui est qu’il ne supporte pas LVM, donc la facilité de redimensionnement ne le concernera pas lui et ses partitions. L’utilisation de LVM et/ou btrfs peut quand même avoir comme avantage de limiter le nombre de partitions nécessaires, dans le but d’éviter le recours aux partitions logiques dans le cas où Windows est amorcé en mode BIOS et exige une table de partition au format MSDOS. (Une autre possibilité, c’est la table de partition hybride GPT+MSDOS, ça marche mais dans le genre bancal c’est pas mal aussi.)[/quote]
Oui il s’agit bien de Windows. En effet alors dans ce cas Windows doit rester sur du NTFS, et pour le dual-boot ou plus avoir une deuxième partition en LVM (pour le couple LVM-btrfs) et à ce moment là répartir les OS sur différents volumes logiques à l’intérieur du LVM.
D’ailleurs en revenant sur l’histoire d’installer plusieurs OS dans des subvolumes btrfs, je voudrais savoir si tous les installateurs d’OS Linux placent l’installation temporaire de ce qui va devenir plus tard la racine dans ce fameux dossier [quote]/target[/quote] ou bien est-ce propre à Debian (et éventuellement dérivées)?
Bonsoir à tous,
Bon je reviens sur ce sujet pour avoir une info puis je finirai par le clore lorsque j’aurais terminé mes essais, ça pourra servir à d’autres.
La question est de savoir si l’on peut redimensionner deux partitions logiques contigües, à savoir les fusionner en une partition unique, le tout se trouvant dans une partition étendue (pas de LVM)?
J’ai le schéma suivant :
|-------- sda1 Recovery Partition 1 NTFS (14GB)
|-------- sda2 System Recovery W$ NTFS (105MB)
|-------- sda3 Windows NTFS (80GB)
|-------- sda4 Partition étendue (406GB)
|
|------------ sda5 Root ext4 (40GB)
|------------ sda6 Swap (6GB)
|------------ sda7 Home ext4 (20GB)
|------------ sda8 Stockage ext4 (330GB)
|------------ sda9 btrfs-test btrfs (10GB)
Donc pour l’instant je fais mon apprentissage avec btrfs sur sda9, l’installation précédente étant sur sda5. À terme si ça me convient je voudrais remplacer celle sur sda5 par celle en btrfs sur sda9 grâce à une migration par snapshot après avoir formaté bien entendu sda5 en btrfs. Ce qui supposerait également de remanier certains fichiers comme le fichier fstab, grub.cfg, …
Mais ce que je souhaiterai faire avant tout ça c’est de fusionner les partitions sda5 et sda7 (puisque je compte exploiter les subvolumes à la rigueur je ne vois plus l’intérêt des partitions dans mon cas puisque je pourrais réinstaller un système neuf dans un subvol sans perdre mon home). Evidemment ça suppose de faire sauter aussi la partition sda6.
Donc la question est comment faire pour réunir ces partitions selon le nouveau schéma suivant :
|-------- sda1 Recovery Partition 1 NTFS (14GB)
|-------- sda2 System Recovery W$ NTFS (105MB)
|-------- sda3 Windows NTFS (80GB)
|-------- sda4 Partition étendue (406GB)
|
|------------ sda5 Root btrfs
|------------ sda6 Stockage btrfs
|------------ sda7 swap
|------------ sda8 partition -test btrfs
Le tout si possible sans migrer d’abord toutes mes données actuelles vers un autre support (car dans ce cas je sais comment faire, je vire tout sur un autre support, je refais mes partitions à ma guise et remet ce qui me convient).
Ton schéma final est impossible : il ne peut exister de partition logique sda9 sans sda8. C’est un des inconvénients du format de partition étendue MSDOS. D’autre part pour quelle raison la partition de swap recréée se retrouverait-elle entre la partition de stockage et la partition de test qui n’ont pas bougé ?
Concernant ton projet de fusion de deux partitions, je ne comprends pas sa motivation. Pourquoi vouloir préserver leur contenu lors de la fusion alors qu’il va bien falloir reformater la partition résultante pour la passer en btrfs ? De toute façon, je ne vois pas comment il serait possible de fusionner deux systèmes de fichiers ext4. Au mieux, on peut copier le contenu de la seconde partition dans la première (si elle a assez d’espace libre), supprimer la seconde et agrandir la première.
[quote=“https://fr.wikipedia.org/wiki/Btrfs”]
Cela étant rappelé :
Plus de 50 % du disque sera utilisé essentiellement pour assurer cette sécurité et cette cohérence
Lors de la panne de chaque disque, il faudra démonter le système de fichier !
La fragmentation sera importante, ce qui peut impacter les performances.
Le fonctionnement interne de Btrfs rend pratiquement impossible de déterminer la quantité d’espace libre : la commande « df » ne correspond en effet qu’à l’espace apparent, pas à l’espace réel pouvant être bien plus grand. Auparavant ce type de problème ne se rencontrait sous Linux qu’avec les fichiers creux (ou « troués »).[/quote]
Je n’ai jamais essayé ce système de fichier, est ce que ceci est vrai, notamment sur l’espace disque et le fragmentation ?
La possibilité de redimensionner un peu comme on souhaite “les partitions” et certains systèmes de fichiers avec LVM ne favorise t’elle pas aussi la fragmentation ?
J’ai été étonné par la facilité actuelle avec laquelle on peut redimentionner la plupart des partitions Windows via les outils qu’il intègre. C’est comparable à du LVM même si ce n’en est pas.
Salut Pascal,
Concernant ton projet de fusion de deux partitions, je ne comprends pas sa motivation. Pourquoi vouloir préserver leur contenu lors de la fusion alors qu’il va bien falloir reformater la partition résultante pour la passer en btrfs ? De toute façon, je ne vois pas comment il serait possible de fusionner deux systèmes de fichiers ext4. Au mieux, on peut copier le contenu de la seconde partition dans la première (si elle a assez d’espace libre), supprimer la seconde et agrandir la première.[/quote]
Désolé c’est une erreur de ma part lors de la correction du schéma des partitions.
En fait je voudrais réarranger mon partitionnement à terme car je me suis rendu compte au fil du temps que je n’avais pas besoin de 40G pour le système de fichiers (à l’époque j’ai préféré voir large 
un peu trop large peut-être…) ni de 20G pour mon /home (utilisateur unique et mon /home ne stocke que les fichiers de config $USER, tout le reste des données est sur /Stockage).
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 :
|-------- sda1 Recovery Partition 1 NTFS (14GB)
|-------- sda2 System Recovery W$ NTFS (105MB)
|-------- sda3 Windows NTFS (80GB)
|-------- sda4 Partition étendue (406GB)
|
|------------ sda5 Root btrfs (20GB)
|------------ sda6 Stockage btrfs (366GB)
|------------ sda7 swap (6GB)
|------------ sda8 partition -test btrfs (20GB)En ce qui concerne la partition sda5 là j’ai mis 20GB car je pense que ça devrait largement suffire même avec des sauvegardes futures à l’aide de snapshots.
En ce qui concerne swap, je l’ai mis après Stockage car je sais que je peux modifier à volonté l’espace qui se trouve “à droite” dans un partitionnement msdos (créer, supprimer, recréer, étendre “par la droite” des partitions). Mais en réalité sa position n’aura pas d’importance pour moi au final si je peux modifier les partitions également par la gauche d’où ma question en réalité (c’est là que j’ai un doute, il me semble que la dernière fois que j’ai essayé de faire ça j’avais pété mon MBR car si je me souviens bien les infos sur le début de chaque partition est enregistré dans la MBR au moment du partitionnement?).
ah oui j’ai oublié une autre question : est-ce que maintenant l’outil de conversion de format de partition vers btrfs est fiable? (pour convertir Stockage)
[quote=“cedric058”]https://fr.wikipedia.org/wiki/Btrfs
[quote]Cela étant rappelé :
Plus de 50 % du disque sera utilisé essentiellement pour assurer cette sécurité et cette cohérence
Lors de la panne de chaque disque, il faudra démonter le système de fichier !
La fragmentation sera importante, ce qui peut impacter les performances.[/quote]
Le fonctionnement interne de Btrfs rend pratiquement impossible de déterminer la quantité d’espace libre : la commande « df » ne correspond en effet qu’à l’espace apparent, pas à l’espace réel pouvant être bien plus grand. Auparavant ce type de problème ne se rencontrait sous Linux qu’avec les fichiers creux (ou « troués »).
Je n’ai jamais essayé ce système de fichier, est ce que ceci est vrai, notamment sur l’espace disque et le fragmentation ?
La possibilité de redimensionner un peu comme on souhaite “les partitions” et certains systèmes de fichiers avec LVM ne favorise t’elle pas aussi la fragmentation ?[/quote]
Je ne sais pas à quoi ils font référence exactement dans l’article wiki, mais je suppose que c’est en relation avec le dernier paragraphe sur RAID et la compression de données… Mais je n’ai jamais utilisé RAID donc aucune idée pour moi.
Par contre pour la fragmentation il me semblait avoir lu recemment le contraire justement, que btrfs permettait de diminuer la fragmentation (qui est déjà minime chez ext3,ext4,…) en laissant un espace non conséquent mais non insignificatif non plus après chaque fichier enregistré, espace immédiatement contigü et dans lequel sont enregistrées uniquement les modifications apportées au fichiers, ce qui limiterait donc la fragmentation qui est par habitude me semble-t-il causée par des modifications enregistrées sur des clusters par forcément contigüs de ceux du fichier en question. Après je n’en sais pas plus et je suis loin d’être un expert en la matière.
Pour l’espace occupé, par exemple chez moi je ne peux voir directement que l’espace occupé sur la partition en question, pourtant sur cette partition j’ai deux subvolumes : /root et /home.
À l’instar de ce que l’on voit classiquement sur une installation où / et /home sont montés sur deux partitions différentes (on voit donc tout de suite la place qu’occupe chaque montage) ici on ne le voit pas directement… Mais bon au travers de l’utilisateur de disques où même en cli il est très facile de le déduire.
Et puis surtout c’est n’est pas quelque chose selon moi de propre à btrfs lui-même mais au partitionnement, que l’on ait une seule partiton ext3,ext4 ou autre et sur cette partition le / et /home, le résultat serait le même…
Oui certainement avec 50 % du disque… 
La je pense que tu te trompes, un volume logique LVM n’est pas vraiment une partition, or chez moi, formaté en ext4 il n’y a aucun problème à ce niveau la.
Oui certainement avec 50 % du disque… [/quote]
Ça doit sans doute être en lien avec des besoins pour serveurs en effet, où des sauvegardes régulières sur de gros systèmes seraient effectuées… Mais même là je ne vois pas comment il pourrait occuper autant de place sachant que le principe des snapshots est justement de prendre une “image” du système à un moment donné mais cette image n’occupe pas de place sur le disque…
Après je n’en sais pas plus c’est encore tout nouveau pour moi aussi donc il y a peut-être quelque chose qui m’échappe et mes propos ne doivent pas être pris pour concluants.
La je pense que tu te trompes, un volume logique LVM n’est pas vraiment une partition, or chez moi, formaté en ext4 il n’y a aucun problème à ce niveau la.[/quote]
Oui mais tu crées plusieurs volumes logiques au sein même d’un volume physique, volumes sur lesquels tu vas après mettre ta racine, ton /home, …
Donc quand tu vas déclarer tes montages dans fstab, le système n’y verra que du feu comme si c’étaient de réelles partitions…
Tandis qu’avec btrfs tu créee des sous-volumes au sein même d’une partition, tu ne peux donc pas déclarer un sous-volume dans ton fstab comme tu le fais pour une partition (enfin pas pour l’instant, peut-être qu’un jour ce sera possible qui sait).
D’où la différence.
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]
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