Czy istnieje sposób monitorowania postępu ponownego zrównoważenia btrfs?


13

Zastępuję uszkodzony dysk twardy w lustrzanym pliku btrfs.

btrfs device delete missing /[mountpoint]trwa bardzo długo, więc zakładam, że w rzeczywistości przywraca dane do dysku zastępczego.

Czy jest jakiś sposób na monitorowanie postępu takiej operacji?

Niekoniecznie oczekuję ładnie wyglądającego GUI, ani nawet licznika%; i jestem gotów napisać kilka wierszy skryptu powłoki, jeśli to konieczne, ale nawet nie wiem, od czego zacząć szukać odpowiednich danych. btrfs filesystem showna przykład po prostu się zawiesza, prawdopodobnie czeka na zakończenie operacji wyważenia, zanim wyświetli jakiekolwiek informacje o lustrzanym fs.

Odpowiedzi:


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
Dzięki, okazuje się, że w moim przypadku btrfs nie wydaje się uważać bieżącej operacji za równowagę, ponieważ to nic nie zwraca, ale widzę też „status zastąpienia”, którego prawdopodobnie mógłbym użyć, gdybym użył polecenia zamiany . Dobra odpowiedź niezależnie.
user50849

Stan równowaga powinna wyglądać mniej więcej tak: Balance on '/volume1' is running 28 out of about 171 chunks balanced (1156 considered), 84% left. Niezwykle procent się odlicza.
mwfearnley

7
sudo btrfs fi show

spowoduje to wyświetlenie czegoś takiego:

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

A jeśli zauważysz, że identyfikator urządzenia nr 4 wygląda nieco inaczej niż reszta. kiedy zrobisz „btrfs device delete missing / mntpoint”, wówczas zacznie się regeneracja metadanych / danych raidu niezbędnych do zwolnienia tego „brakującego” dysku.

jeśli zrobisz coś takiego

"watch -n 10 sudo btrfs fi show"

wtedy zobaczysz, że miejsce na „zaginionym” urządzeniu naruszającym stopniowo maleje, aż do zakończenia operacji i zostanie usunięte z fi.


4

BTRFS może potrzebować trochę czasu na odczyt lub zmianę kolejności danych przed zapisaniem danych na dysku, na którym chcesz je zapisać.

Możesz zobaczyć, ile czasu procesora przeznacza się na operacje BTRFS, w tym przywracanie równowagi, dodawanie, usuwanie, konwersję itp .:

ps -ef | grep btrfs

Aby zobaczyć, jak zajęty jest każdy dysk, zainstaluj sysstat i uruchom:

iostat

Dodaj kilka opcji, aby iostat wyświetlał statystyki w megabajtach i aktualizował co 30 sekund:

iostat -m -d 30

Przykładowe dane wyjściowe ze szorowania, aby nie zapisywać w tym okresie:

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

Zainstaluj i uruchom munina, aby zobaczyć historyczne wykresy aktywności dysku i wiele innych informacji. https://www.digitalocean.com/community/tutorials/how-to-install-the-munin-monitoring-tool-on-ubuntu-14-04


1

Zastanawiałem się także, kiedy skończy się długotrwałe usuwanie, więc wymyśliłem ten mały fragment kodu powłoki:

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

To da ci fajny pasek postępu taki jak ten:

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

Ogólnym pomysłem jest użycie pvdo wyświetlenia postępu. Ponieważ to polecenie pozwala tylko monitorować bajty przepływające przez potok, używamy dddo generowania odpowiedniej liczby zer i przesyłania ich do potoku pv.

Zaletą tej metody jest to, że masz ładny pasek postępu. Ponieważ jednak wydaje się, że btrfszawsze usuwa dane jeden GB na raz, potrzeba czasu, zanim można zaobserwować nową różnicę w rozmiarach bajtów.

Aby rozwiązać ten problem, flaga -ajest dodawana do domyślnych flag, pvaby wyświetlać średnią szybkość transmisji (ponieważ normalna bieżąca szybkość transmisji będzie wynosić 0 przez większość czasu).

Zdaję sobie sprawę, że nie jest to najlepsze rozwiązanie, ale najlepsze, jakie mogłem wymyślić. Jeśli ktoś ma pomysły na ulepszenia, daj mi znać! :)

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.