Existe-t-il un moyen de suivre la progression d'un rééquilibrage btrfs?


13

Je remplace un disque dur défectueux dans un btrfs en miroir.

btrfs device delete missing /[mountpoint]prend très longtemps, donc je suppose qu'il s'agit en fait d'un rééquilibrage des données sur le disque de remplacement.

Existe-t-il un moyen de suivre l'avancement d'une telle opération?

Je ne m'attends pas nécessairement à une jolie interface graphique, ni même à un compteur%; et je suis prêt à écrire quelques lignes de script shell si cela est nécessaire, mais je ne sais même pas par où commencer pour rechercher des données pertinentes. btrfs filesystem showpar exemple, se bloque simplement, attendant probablement la fin de l'opération d'équilibrage avant d'afficher des informations sur les fs en miroir.

Réponses:


25
btrfs balance status /mountpoint

man 8 btrfs

 [filesystem] balance status [-v] <path>
        Show status of running or paused balance.

        Options

        -v   be verbose

4
Merci, il s'avère que dans mon cas, btrfs ne semble pas considérer l'opération en cours comme un équilibre, car cela ne renvoie rien, mais je vois qu'il y a aussi un "état de remplacement", que j'aurais probablement pu utiliser si j'avais utilisé la commande replace . Bonne réponse malgré tout.
user50849

L'état de l' équilibre devrait ressembler à : Balance on '/volume1' is running 28 out of about 171 chunks balanced (1156 considered), 84% left. Fait inhabituel, le pourcentage décompte.
mwfearnley

7
sudo btrfs fi show

cela produira quelque chose comme ceci:

Label: none  uuid: 2c97e7cd-06d4-4df0-b1bc-651397edf74c
        Total devices 16 FS bytes used 5.36TiB
        devid    1 size 931.51GiB used 770.48GiB path /dev/sdc
        devid    2 size 931.51GiB used 770.48GiB path /dev/sdg
        devid    3 size 931.51GiB used 770.48GiB path /dev/sdj
        devid    4 size 0.00 used 10.02GiB path
        devid    5 size 931.51GiB used 770.48GiB path /dev/sdh
        devid    6 size 931.51GiB used 770.48GiB path /dev/sdi
        devid    7 size 931.51GiB used 770.48GiB path /dev/sdd
        devid    8 size 931.51GiB used 770.48GiB path /dev/sdo
        devid    9 size 465.76GiB used 384.31GiB path /dev/sdn
        devid    10 size 931.51GiB used 770.48GiB path /dev/sdp
        devid    11 size 931.51GiB used 770.48GiB path /dev/sdr
        devid    12 size 931.51GiB used 770.48GiB path /dev/sdm
        devid    13 size 931.51GiB used 769.48GiB path /dev/sdq
        devid    14 size 931.51GiB used 770.48GiB path /dev/sdl
        devid    15 size 931.51GiB used 770.48GiB path /dev/sde
        devid    16 size 3.64TiB used 587.16GiB path /dev/sdf

Btrfs v3.12

Et si vous remarquez que l'identifiant d'appareil n ° 4 est un peu différent du reste. lorsque vous effectuez la "suppression de périphérique btrfs manquant / mntpoint", il commencera à régénérer les méta / données de raid nécessaires pour libérer ce lecteur "manquant".

si vous faites quelque chose comme

"watch -n 10 sudo btrfs fi show"

vous pouvez alors voir l'espace sur le périphérique "manquant" incriminé de plus en plus petit jusqu'à ce que l'opération soit terminée et qu'il soit supprimé du fi.


4

BTRFS peut prendre un certain temps à lire ou à réorganiser les données avant d'écrire des données sur le lecteur sur lequel vous vous attendez à ce qu'elles écrivent.

Vous pouvez voir combien de temps CPU est consacré aux opérations BTRFS, y compris le rééquilibrage, l'ajout, la suppression, la conversion, etc.:

ps -ef | grep btrfs

Pour voir à quel point chaque lecteur est occupé, installez sysstat et exécutez:

iostat

Ajoutez des options pour que iostat affiche les statistiques en mégaoctets et mettez à jour toutes les 30 secondes:

iostat -m -d 30

Exemple de sortie de scrub afin qu'aucune écriture pendant cet intervalle:

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sda             700.30       170.10         0.00       6804          0
sdb               0.78         0.00         0.01          0          0
sdc             520.20       127.98         0.00       5119          0
sdd             405.72        92.02         0.00       3680          0
sde             630.05       153.66         0.00       6146          0
sdf             627.43       153.60         0.00       6144          0

Installez et exécutez munin pour voir des graphiques historiques de l'activité du lecteur et de nombreuses autres informations. https://www.digitalocean.com/community/tutorials/how-to-install-the-munin-monitoring-tool-on-ubuntu-14-04


1

Je me demandais également quand une suppression durable se terminerait, alors j'ai trouvé ce petit morceau de code shell:

get_bytes() {
  btrfs device usage --raw /mnt/data | egrep -- '-[0-9]+' | sed -E 's/[^0-9]+([0-9]+)/\1/'
}

prev=$(get_bytes)

while [ 1 ]; do
  current=$(get_bytes)
  diff=$((current-prev))
  if [ "$diff" -gt 0 ]; then
    dd if=/dev/zero iflag=count_bytes count="$diff" 2>/dev/null
  fi
  prev="$current"
  sleep 1
done | pv -petraW -s $(get_bytes) >/dev/null

Cela vous donnera une belle barre de progression comme celle-ci:

0:13:54 [0,00 B/s] [16,0MiB/s] [>                             ]  1% ETA 19:23:19

L'idée générale est d'utiliser pvpour afficher les progrès. Étant donné que cette commande permet uniquement de surveiller les octets circulant dans un tuyau, nous utilisons ddpour générer une quantité appropriée de zéros et les diriger vers pv.

L'avantage de cette méthode est que vous obtenez une belle barre de progression. Cependant, comme il semble btrfstoujours supprimer les données un Go à la fois, cela prend un certain temps jusqu'à ce qu'une nouvelle différence dans la taille des octets puisse être observée.

Pour résoudre ce problème, l'indicateur -aest ajouté aux indicateurs par défaut de pvpour lui faire afficher un taux de transmission moyen (car le taux de transmission actuel normal sera 0 la plupart du temps).

Je me rends compte que ce n'est pas la meilleure solution mais la meilleure que j'ai pu trouver. Si quelqu'un a des idées d'améliorations, faites-le moi savoir! :)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.