Journal Migration de / d'un disque dur à l'autre avec btrfs

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
24
27
nov.
2017

Bonjour,

Suite aux bons journaux trouvés sur linuxfr à propos de btrfs,
j'ai transformé mes systèmes de fichier principaux en btrfs pour pouvoir
bénéficier de ses avantages et de snapperd.

Aujourd'hui, j'ai fait une mise à jour de mon nas pour passer du ssd au nvme.

Le nouveau disque est plus petit que l'ancien, je ne peux pas faire une bête
copie bit à bit de l'ancien disque vers le nouveau comme je fais à mon habitude.

Au vu des quelques sous-volumes que j'ai (69), il est hors de question aussi
que je recréé l'arborescence des sous-volumes et que je fasse des copies.

Du coup, j'ai eu l'idée d'étendre le système de fichier avec le nouveau disque, puis
de retirer l'ancien.

Voilà ce que ça donne sur la ligne de commande:

[root:~] # # Nombre de sous-volumes
[root:~] # btrfs sub list / |wc
     69     621    4447
[root:~] # # Taille du volume btrfs avant:
[root:~] # df -h /
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sdd2          476G    103G  373G  22% /
[root:~] # # ajout du nouveau disque
[root:~] # btrfs device add /dev/nvme0n1 /
Performing full device TRIM /dev/nvme0n1 (232.89GiB) ...
[root:~] # # Nouvelle taille intermédiaire
[root:~] # df -h /
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sdd2          709G    103G  606G  15% /
[root:~] # # suppression de l'ancien disque
[root:~] # btrfs device delete /dev/sdd2 /
[root:~] 2h16m58s #

Et tout ça à chaud sans avoir besoin d'arrêter le système, sauf pour retirer l'ancien disque.

Le seul bémol que je trouve à utiliser btrfs c'est que les opérations
peuvent être lentes parfois. Ici, j'ai déplacé 103Go en 2h16, soit du 12Mo/s …

Heureusement que c'est du ssd !

Je n'ai pas trouvé non plus comment voir la progression de l'opération 'device delete'.
J'aurais peut-être dû utiliser la commande 'balance' pour pouvoir voir la progression en
temps réel.

Btrfs, c'est bon ! mangez-en ;)

  • # Simulation pmove

    Posté par  . Évalué à 8.

    J'ai effectué plusieurs fois le même type d'opérations dans des conditions légèrement différentes.

    Notamment sur un ordinateur portable et un DD externe, condition qui ne me permettait pas de faire l'opération btrfs device delete simplement. En effet, device delete doit être effectué d'une traite sans arrêt possible et dans mon cas j'avais trop de données pour que cela puisse se faire en une nuit.

    Solution: réduire la taille du disque source via un btrfs fi resize d'une taille juste supérieure à la taille utilisée puis à coup de btrfs balance avec un filtre devid on peut bouger les chunks d'une disque à l'autre par une opération interruptible. C'est équivalent à un pvmove de LVM.
    Quand tout est transféré, on passe au btrfs device delete final.

    • [^] # Re: Simulation pmove

      Posté par  . Évalué à 3.

      En complément,

      Ce que je décris là-haut est un gros trucage pour feinter l'allocateur de chunks de btrfs. L'allocateur décide toujours de réserver un chunk sur le disque qui contient le plus d'espace libre. En appelant, btrfs balance avec le filtre devid on indique uniquement que l'on veut ré-allouer les chunks présents sur le disque source. Par contre il n'y a aucun moyen de préciser explicitement où on veut qu'ils aillent. En ayant fait le btrfs fi resize (attention ! avec l'option devid précisant qu'on réduit la taille du disque source), on ne laisse plus de place sur le disque source. L'allocateur va donc déplacer les chunks du disque source au disque cible.

      Pour revenir à BTRFS, il y a quand même plusieurs manquements soit dans l'implémentation actuelle soit dans le système en lui même. Citons par exemple:

      • le pmove comme simuler ici
      • une politique configurable de l'allocateur (pour par exemple prendre en compte une configuration hybride hdd/ssd)
      • des profils RAID par sous-volume

      A priori, les manquements ci-dessus sont réalisables sans modifier le format disque, mais juste les outils et le driver tout en étant retro-compatible. Certains sont dans les tuyaux.

      Par contre, les profils RAID sont codés assez simplement dans le format du fs (DUP/RAID0/RAID1) ce qui à mon avis limitera l'évolution du système. On pourrait par exemple imaginer des profils du type, je veux au moins 3 copies réparties sur au moins 2 disques physiques. Aujourd'hui sans changer le format disque ce n'est pas possible.

  • # Pareil avec LVM

    Posté par  (site web personnel) . Évalué à 8. Dernière modification le 28 novembre 2017 à 17:10.

    J'ai longtemps fait pareil avec simplement LVM, et c'est d'ailleurs une des raisons pour lesquelles je mets du LVM partout, même si je n'utilise pas toujours sa fonctionnalité principale, à savoir le redimensionnement libre.

    Bref, pour info, avec LVM, pour passer tous les volumes logiques d'un groupe de volume toto — personnellement, je nomme toujours mon groupe de volume du nom de la machine, afin de ne pas avoir de conflit si je dois brancher son disque dur ailleurs — d'un périphérique que nous appellerons sda3 vers un autre qui sera sdb3 :

    pvcreate /dev/sdb3
vgextend toto /dev/sdb3
pvmove /dev/sda3 /dev/sdb3
vgreduce toto /dev/sda3

    J'ai eu un jour un problème avec cela : afin de faire ce déplacement, j'avais branché le nouveau périphérique sur un contrôleur SATA sur USB. Or ce dernier a coupé la connexion au beau milieu du pvmove. Le résultat était catastrophique, je n'ai rien pu récupérer, de sorte que j'ai dû repartir de sauvegardes…

    • [^] # Re: Pareil avec LVM

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

      Pourtant la page de man de pvmove se montre rassurante :

      If pvmove gets interrupted for any reason (e.g. the machine crashes) then run pvmove again without any PhysicalVolume arguments to restart any moves that were in progress from the last checkpoint.

      Adhérer à l'April, ça vous tente ?

      • [^] # Re: Pareil avec LVM

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 29 novembre 2017 à 11:33.

        Certes, sauf qu'il n'avait pas simplement été interrompu, dans ce cas : le périphérique cible avait soudainement disparu. Le groupe de volume contenait toujours le nouveau volume physique, sauf que celui-ci était inexistant. J'ai bien essayé de débrancher, puis de débrancher le nouveau disque dur, ce qui lui a fait prendre un nouveau nom, à savoir sdc. Et en essayant de reprendre le pvmove, rien à faire, ça essayait de continuer à transférer vers sdb qui n'existait pas.

        En tout cas, j'ai essayé tout ce à quoi j'avais pu penser, et je n'ai trouvé aucun moyen de récupérer mes volumes logiques d'une quelconque façon…

    • [^] # Re: Pareil avec LVM

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

      J'ai utilisé cette technique pour faire des migrations d'un SAN à un autre, ça marchait très bien.

Suivre le flux des commentaires

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