Топик чисто ознакомительный, даёт некоторое представление об отказоустойчивости btrfs в 2020.
Несколько недель назад был отвал устройств на USB3 хабе моего домашнего сервера. Тогда не придал этому внимания. Как оказалось, бобик начал подыхать. На нём, в числе прочего, внешний USB3 винт.
В какой-то момент в логе начался флуд разнообразных сообщений об ошибках usb-устройств, а примонтированная ФС ушла в астрал:
aidaho@optiplex:~$ la /home/aidaho/.config/calibre/Library/
ls: /home/aidaho/.config/calibre/Library/: Input/output error
ls: /home/aidaho/.config/calibre/Library/.: Input/output error
ls: /home/aidaho/.config/calibre/Library/..: Input/output error
ls: reading directory '/home/aidaho/.config/calibre/Library/': Input/output error
total 16K
drwxrwx--- 1 aidaho aidaho 3.7M Mar 9 14:51 ./
drwxrwxrwx 1 root root 84 Jun 3 2019 ../
~/.config/calible/Library — это симлинк на btrfs книгохранилище.
Переткнул хаб и попробовал починить:
root@optiplex:/home/aidaho# btrfs check --repair --progress /dev/dm-2
enabling repair mode
Opening filesystem to check...
Checking filesystem on /dev/dm-2
UUID: 39ca2053-7da1-4aa2-ad78-97697235bf06
[1/7] checking root items (0:03:06 elapsed, 5236043 items checked)
Fixed 0 roots.
No device size related problem found (0:01:49 elapsed, 386801 items checked)
[2/7] checking extents (0:01:50 elapsed, 386801 items checked)
cache and super generation don't match, space cache will be invalidated
[3/7] checking free space cache (0:00:00 elapsed)
root 5 inode 2954758 errors 100, file extent discount03 elapsed, 175202 items checked)
Found file extent holes:
start: 0, len: 1019904
[4/7] checking fs roots (0:02:04 elapsed, 175635 items checked)
ERROR: errors found in fs roots
found 2856969207808 bytes used, error(s) found
total csum bytes: 2783138772
total tree bytes: 6337216512
total fs tree bytes: 2888613888
total extent tree bytes: 486735872
btree space waste bytes: 699123598
file data blocks allocated: 2865043968000
referenced 3103189127168
Повторный пуск даёт тот же вывод:
root@optiplex:/home/aidaho# btrfs check --repair --progress /dev/dm-2
enabling repair mode
Opening filesystem to check...
Checking filesystem on /dev/dm-2
UUID: 39ca2053-7da1-4aa2-ad78-97697235bf06
[1/7] checking root items (0:04:00 elapsed, 5236055 items checked)
Fixed 0 roots.
No device size related problem found (0:01:52 elapsed, 386806 items checked)
[2/7] checking extents (0:01:53 elapsed, 386806 items checked)
cache and super generation don't match, space cache will be invalidated
[3/7] checking free space cache (0:00:00 elapsed)
root 5 inode 2954758 errors 100, file extent discount56 elapsed, 175434 items checked)
Found file extent holes:
start: 0, len: 1019904
[4/7] checking fs roots (0:01:56 elapsed, 175635 items checked)
ERROR: errors found in fs roots
found 2856969289728 bytes used, error(s) found
total csum bytes: 2783138772
total tree bytes: 6337298432
total fs tree bytes: 2888630272
total extent tree bytes: 486768640
btree space waste bytes: 699202955
file data blocks allocated: 2865043968000
referenced 3103189127168
Итак, на ФС есть ошибки, которые btrfs check не спешит исправлять.
Попробуем смонтировать:
[2386028.604438] BTRFS info (device dm-2): disk space caching is enabled
[2386028.604442] BTRFS info (device dm-2): has skinny extents
[2386028.889649] BTRFS info (device dm-2): bdev /dev/mapper/luks-94bd2ae6-fb3b-4098-802f-da26255ed489 errs: wr 10, rd 0, flush 0, corrupt 0, gen 0
[2386031.073168] BTRFS info (device dm-2): checking UUID tree
На удивление, ФС смонтировалась в rw и продолжила работать без каких-то видимых нюансов. Визуально всё на месте и запись работает как положено.
Теперь интересное:
Был запущен btrfs scrub который исправил целую кучу (емнип, около двух сотен) checksum errors.
Хотя в USB вроде и есть какая-то коррекция ошибок, но хаб её успешно поборол.
Где-то во время его работы хаб вновь ушёл в астрал и накопитель заработал третий хардварный креш.
Третий заход btrfs check после перетыкания хаба:
root@optiplex:/home/aidaho# btrfs check --repair --progress /dev/dm-2
enabling repair mode
Opening filesystem to check...
Checking filesystem on /dev/dm-2
UUID: 39ca2053-7da1-4aa2-ad78-97697235bf06
parent transid verify failed on 1958979633152 wanted 3776 found 3635 items checked)
parent transid verify failed on 1958979633152 wanted 3776 found 3635
parent transid verify failed on 1958979633152 wanted 3776 found 3635
parent transid verify failed on 1958979633152 wanted 3776 found 3635
Ignoring transid failure
parent transid verify failed on 1958979321856 wanted 3776 found 3635301 items checked)
parent transid verify failed on 1958979321856 wanted 3776 found 3635
parent transid verify failed on 1958979321856 wanted 3776 found 3635
parent transid verify failed on 1958979321856 wanted 3776 found 3635
Ignoring transid failure
parent transid verify failed on 1958979338240 wanted 3776 found 3635
parent transid verify failed on 1958979338240 wanted 3776 found 3635
parent transid verify failed on 1958979338240 wanted 3776 found 3635
parent transid verify failed on 1958979338240 wanted 3776 found 3635
Ignoring transid failure
parent transid verify failed on 1958979371008 wanted 3776 found 3635091 items checked)
parent transid verify failed on 1958979371008 wanted 3776 found 3635
parent transid verify failed on 1958979371008 wanted 3776 found 3635
parent transid verify failed on 1958979371008 wanted 3776 found 3635
Ignoring transid failure
parent transid verify failed on 1958979420160 wanted 3776 found 3635
parent transid verify failed on 1958979420160 wanted 3776 found 3635
parent transid verify failed on 1958979420160 wanted 3776 found 3635
parent transid verify failed on 1958979420160 wanted 3776 found 3635
Ignoring transid failure
parent transid verify failed on 1958979436544 wanted 3776 found 3635213 items checked)
parent transid verify failed on 1958979436544 wanted 3776 found 3635
parent transid verify failed on 1958979436544 wanted 3776 found 3635
parent transid verify failed on 1958979436544 wanted 3776 found 3635
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=1959335247872 item=71 parent level=1 child level=1
[1/7] checking root items (0:00:16 elapsed, 473935 items checked)
ERROR: failed to repair root items: Input/output error
Ну всё: бобик теперь совсем помер. Попробуем смонтировать эти руины:
[ 126.775723] BTRFS: device label armor devid 1 transid 3782 /dev/dm-2
[ 127.048174] BTRFS info (device dm-2): disk space caching is enabled
[ 127.048176] BTRFS info (device dm-2): has skinny extents
[ 127.451449] BTRFS info (device dm-2): bdev /dev/mapper/luks-94bd2ae6-fb3b-4098-802f-da26255ed489 errs: wr 10, rd 0, flush 0, corrupt 0, gen 122
[ 149.256547] BTRFS error (device dm-2): parent transid verify failed on 1958979633152 wanted 3776 found 3635
[ 149.266134] BTRFS error (device dm-2): parent transid verify failed on 1958979633152 wanted 3776 found 3635
[ 149.266155] BTRFS: error (device dm-2) in btrfs_run_delayed_refs:2935: errno=-5 IO failure
[ 149.266161] BTRFS info (device dm-2): forced readonly
[ 149.266165] BTRFS warning (device dm-2): Skipping commit of aborted transaction.
[ 149.266168] BTRFS: error (device dm-2) in cleanup_transaction:1860: errno=-5 IO failure
[ 149.266202] BTRFS error (device dm-2): commit super ret -5
Неисправная (и уже неисправимая) ФС по прежнему монтируется в RO и файлы доступны. Точно ли доступны? Переткнул винт уже прямо в порт материнки и на ночь поставил копировать всё в /dev/null
На удивление, не скопировался только один видеофайл.
Выводы: ну, это однозначно зачёт.
N лет тому назад был свидетелем тому, как помирающий мост одной материнки поделил на ноль ext3 тем же образом.
Тут не смотря на столько битфлипов всё даже как-то продолжало работать, а когда совсем накрылось, всё равно можно было встать и уйти практически со всеми данными.
Я считаю, флаг nochecksum для btrfs нужно просто запретить, как предложенный врагами народа.
