Вопросы Теги

Могу ли я перезагрузиться во время замены btrfs, а затем возобновить ее?

Вы можете проверить вывод 'dmesg' на 'смонтированный' следующим образом: dmesg -T | grep 'connected' и если вы хотите контролировать его, если он уже установлен, вы можете использовать inotify, но имейте в виду, что это строго решение для Linux, поэтому для Unix вам нужно будет использовать какой-то другой инструмент для мониторинга активности файловой системы.

3
27.08.2016, 10:45
2 ответа

Возобновляем этот вопрос, потому что это самый высокий результат Google при поиске «btrfs replace резюме», а существующий ответ не раскрывает всей истории.

Процесс замены автоматически возобновляется после перезагрузки (так же, как балансировка ). Мне даже пришлось выполнить аппаратный сброс -во время операции замены, и процесс благополучно продолжился после перезагрузки и перемонтирования файловой системы. Итак, я предполагаю, что все эти проблемы sssheridan вызвала не сама прерванная операция замены, а обстоятельства, связанные с загрузкой с умирающего жесткого диска.

При монтаже после прерванной замены печатается подобная строка журнала -:

BTRFS info (device sdh1): continuing dev_replace from /dev/sdb1 (devid 5) to target /dev/sdh1 @95%

Последнее число — это процент завершения.

2
27.01.2020, 21:22

TL;DR:

Да. Но после этого запустите scrub.

Полная версия:

В этой статье LWN приводится текст коммита для replaceи говорится:

It is safe to crash or lose power during the operation, the process resumes with the next mount.

Я перезагрузился со своим replaceпримерно на 5%, потому что замена btrfs на RAID1 была очень медленной при наличии отказавшего диска .

После возобновления и завершения replaceя заметил, что btrfs device usage /mountpointпоказывает некоторые Data,DUPи Metadata,single, а не только RAID1. Вероятно, это произошло из-за того, что btrfsзаписывает DUP, поскольку он не может записать вторую копию на отказавший диск. Я сделал ребалансировку, чтобы сделать все RAID1:

btrfs balance start -dconvert=raid1,soft -mconvert=raid1,soft /mountpoint

Теперь все данные отображались как RAID1, я решил просто проверить, все ли в порядке:

btrfs scrub start -Bd /mountpoint

Я рад, что сделал это, так как у меня есть много csum errorsразмером около 151 ГБ, очищенных наid 2(недавно замененном устройстве):

scrub device /dev/mapper/vg4TBd3-ark (id 1) status
        scrub started at Mon Jan 28 20:47:33 2019, running for 00:41:40
        total bytes scrubbed: 153.53GiB with 0 errors
scrub device /dev/mapper/vg6TBd1-ark (id 2) status
        scrub started at Mon Jan 28 20:47:33 2019, running for 00:41:40
        total bytes scrubbed: 151.49GiB with 174840 errors
        error details: csum=174840
        corrected errors: 174837, uncorrectable errors: 0, unverified errors: 0

scrubв этот момент полз. В журналах было много строк типа:

BTRFS warning (device dm-5): checksum error at logical 3425803567104 on dev /dev/mapper/vg6TBd1-ark, physical 162136981504, root 5, inode 3367374, offset 0, length 4096, links 1 (path: HDDs/Quantum LM30/Linux1/home/tn/uts.old/etc/root/home/tn/build/linux-2.4.13-ac8/linux/include/net/sock.h)
BTRFS error (device dm-5): bdev /dev/mapper/vg6TBd1-ark errs: wr 0, rd 0, flush 0, corrupt 1, gen 0                                                                               
BTRFS error (device dm-5): fixed up error at logical 3425803567104 on dev /dev/mapper/vg6TBd1-ark                                                                                 
scrub_handle_errored_block: 806 callbacks suppressed

В итоге я исправил в общей сложности 262016 ошибок, когда я в следующий раз проверил 184GiB, очищенный (, он снова успешно увеличивался в этой точке ).

После этого я не получил ни одной ошибки, что означает, что все ошибки были сосредоточены вокруг точки 151GiB.

151 ГиБ — это примерно 5 % от моих 2,88 ТиБ.точка, в которой я перезапустил.

Возможно, это было просто совпадение -, но я рад, что побежал scrubнесмотря ни на что.

0
27.01.2020, 21:22

Теги

Похожие вопросы