Чи є спосіб відстежити хід відновлення балансу btrfs?


13

Я замінюю невдалий жорсткий диск у дзеркальному btrfs.

btrfs device delete missing /[mountpoint]займає дуже багато часу, тому я припускаю, що це фактично перебалансування даних через привід заміни.

Чи є можливість контролювати хід такої операції?

Я не обов'язково очікую гарного вигляду графічного інтерфейсу або навіть% лічильника; і я готовий написати пару рядків сценарію оболонки, якщо це необхідно, але я навіть не знаю, з чого почати шукати відповідні дані. btrfs filesystem showнаприклад, просто висить, імовірно, чекаючи завершення операції балансу, перш ніж вона відобразить будь-яку інформацію про дзеркальний фс.

Відповіді:


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
Дякую, виявляється, що в моєму випадку btrfs, здається, не вважає поточну операцію рівновагою, оскільки це нічого не повертає, але я бачу, що є також "статус заміни", який, можливо, я міг би використати, якби я використав команду заміни . Гарна відповідь незалежно.
user50849

Статус баланс повинен виглядати приблизно так: Balance on '/volume1' is running 28 out of about 171 chunks balanced (1156 considered), 84% left. Незвичайно відсоток відлічується.
mwfearnley

7
sudo btrfs fi show

це виведе щось подібне:

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

І якщо ви помітили, що ідентифікатор пристрою №4 виглядає дещо інакше, ніж решта. коли ви зробите "btrfs пристрій видалити відсутні / mntpoint", тоді він почне регенерувати мета / дані рейду, необхідні для звільнення цього "відсутнього" накопичувача.

якщо ти робиш щось подібне

"watch -n 10 sudo btrfs fi show"

тоді ви можете побачити простір на ображеному "відсутньому" пристрої, який поступово зменшується і зменшується, поки операція не завершиться, і вона буде видалена з фіг.


4

BTRFS може зайняти деякий час читання або перестановки даних до запису даних на диск, на який ви очікуєте, що вони записують.

Ви можете бачити, скільки часу на процесорі приділяється операціям BTRFS, включаючи перебалансування, додавання, видалення, перетворення тощо:

ps -ef | grep btrfs

Щоб побачити, наскільки зайнятий кожен диск, встановіть sysstat та запустіть:

iostat

Додайте кілька варіантів, щоб стати статистикою показ йостату в мегабайти та оновлювати кожні 30 секунд:

iostat -m -d 30

Вихід зразка з скрабу, тому не записує протягом цього інтервалу:

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

Встановіть і запустіть munin, щоб переглянути історичні графіки активності диска та багато іншої інформації. https://www.digitalocean.com/community/tutorials/how-to-install-the-munin-monitoring-tool-on-ubuntu-14-04


1

Мені також було цікаво, коли закінчиться довготривале видалення, тому я придумав цей маленький шматочок коду оболонки:

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

Це дасть вам хороший бар прогресу, як це:

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

Загальна ідея - використовувати pvдля відображення прогресу. Оскільки ця команда дозволяє лише відстежувати байти, що протікають через трубу, ми використовуємо ddдля створення відповідної кількості нулів і передачі в них pv.

Перевага цього методу полягає в тому, що ви отримуєте хорошу смужку прогресу. Однак, оскільки, здається, btrfsзавжди видаляються дані по одному ГБ за один раз, це потребує певного часу, поки не буде помічена нова різниця у розмірах байтів.

Для вирішення цього питання прапор -aдодається до прапорів за замовчуванням, pvщоб він відображав середню швидкість передачі (оскільки нормальна швидкість поточної передачі буде більшою частиною часу).

Я усвідомлюю, що це не найкраще рішення, але найкраще, що я міг придумати. Якщо у когось є ідеї щодо вдосконалень, будь ласка, повідомте мене! :)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.