Доигрался я.
Вчера эксперименитровал с Gnome. Сегодня нужно работать, решил вернуть все как было. Для этого, я вчера зараннее сделал снимки @ и @home. Сегодня загружаюсь с live usb, монтирую диск, грохаю @ и @home и переименовую в них @_bak и @home_bak. Все как и раньше, проблем никаких не ожидалось. Делаю umount, перезагружаю иии. Система виснет. Ну я думаю, ну и пусть. Вытаскиваю флешку, делаю хард ребут. И вижу, что grub побит. Я гружусь опять с live-usb, монтирую раздел и вижу картину: @_bak и @home_bak так и остались не переименованы. Я опять повторяю переименование. Отмонтирую. Система опять виснет. Все то же самое.
Короче говоря система зависает через некоторое время при попытке примонтировать этот раздел с btrfs. Виснет даже если пытаюсь примонтировать с -o recovery. При этом в dmesg никаких ошибок нет, если успеть глянуть до зависания. То есть, раздел монитруется, выдается парочка info сообщений и все. Пытался снять образ метаданных с помощью btrfs-image:
checksum verify failed on 109525037056 found E7B96D00 wanted 00013CCE
checksum verify failed on 109525037056 found E7B96D00 wanted 00013CCE
bytenr mismatch, want=109525037056, have=13849131797419321567
Error reading metadata block
Error adding space cache blocks -5
checksum verify failed on 109525037056 found E7B96D00 wanted 00013CCE
checksum verify failed on 109525037056 found E7B96D00 wanted 00013CCE
bytenr mismatch, want=109525037056, have=13849131797419321567
Error reading metadata block
Error flushing pending -5
create failed (Success)
Дела плохи.
Спойлер: перенести снимок на другой диск мне видимо религия не позволила. А раньше всегда делал. ССЗБ.
Да, это SSD. SMART в полном порядке.
Работа стала, пойду гуглить. Я даже не знаю, с чего начинать пробовать восстановление. Как мне сейчас сделать резервный снимок раздела без монтирования? А то почитал вики, написано, что можно и угробить то что осталось, если не правильно восстанавливать.
Пользователь добавил сообщение 11 Апреля 2017, 11:15:42:
Вывод btrfs check:
Checking filesystem on /dev/sda2
UUID: df0c8954-9602-465f-82ac-b5039aecbcf0
checking extents
corrupt extent record: key 109524959232 168 77824
corrupt extent record: key 109525037056 168 81920
corrupt extent record: key 109525118976 168 81920
corrupt extent record: key 109525200896 168 98304
corrupt extent record: key 109525299200 168 94208
ref mismatch on [109524873216 86016] extent item 16898097290397089221, found 1
ref mismatch on [109524959232 77824] extent item 16951580881043191694, found 1
Backref 109524959232 root 460 owner 5227682 offset 6684672 num_refs 0 not found in extent tree
Incorrect local backref count on 109524959232 root 460 owner 5227682 offset 6684672 found 1 wanted 0 back 0x28292a0
backpointer mismatch on [109524959232 77824]
ref mismatch on [109525037056 81920] extent item 5213254701863807789, found 1
Backref 109525037056 root 460 owner 5227682 offset 6946816 num_refs 0 not found in extent tree
Incorrect local backref count on 109525037056 root 460 owner 5227682 offset 6946816 found 1 wanted 0 back 0x4d25c90
backpointer mismatch on [109525037056 81920]
bad metadata [109525037056, 109525118976) crossing stripe boundary
bad extent [109525037056, 109525118976), type mismatch with chunk
ref mismatch on [109525118976 81920] extent item 14857125596567025771, found 1
Backref 109525118976 root 460 owner 5227682 offset 7340032 num_refs 0 not found in extent tree
Incorrect local backref count on 109525118976 root 460 owner 5227682 offset 7340032 found 1 wanted 0 back 0x5d99220
backpointer mismatch on [109525118976 81920]
bad metadata [109525118976, 109525200896) crossing stripe boundary
bad extent [109525118976, 109525200896), type mismatch with chunk
ref mismatch on [109525200896 98304] extent item 7905649980062840434, found 1
Backref 109525200896 root 460 owner 5227682 offset 7471104 num_refs 0 not found in extent tree
Incorrect local backref count on 109525200896 root 460 owner 5227682 offset 7471104 found 1 wanted 0 back 0x1144570
backpointer mismatch on [109525200896 98304]
Backref 109525299200 root 460 owner 5227682 offset 7602176 num_refs 0 not found in extent tree
Incorrect local backref count on 109525299200 root 460 owner 5227682 offset 7602176 found 1 wanted 0 back 0x2829170
backpointer mismatch on [109525299200 94208]
checking free space cache
checking fs roots
checking csums
checking root refs
found 31646085232 bytes used err is 0
total csum bytes: 29957896
total tree bytes: 937000960
total fs tree bytes: 845692928
total extent tree bytes: 50610176
btree space waste bytes: 189405528
file data blocks allocated: 45980393472
referenced 42949767168
Пользователь добавил сообщение 11 Апреля 2017, 11:31:50:
Дальше по очереди, что я пытался сделать:
sudo btrfs rescue zero-log /dev/sda2:
Clearing log on /dev/sda2, previous log_root 0, level 0
sudo btrfs rescue chunk-recover /dev/sda2
Scanning: DONE in dev0
Check chunks successfully with no orphans
Chunk tree recovered successfully
sudo btrfs rescue super-recover /dev/sda2
All supers are valid, no need to recover
Сейчас сделаю копию через btrfs restore и пойду дальше пытаться.
Пользователь добавил сообщение 11 Апреля 2017, 11:54:18:
Отработало btrfs restore. Ошибок вроде нет, визуально восстановленные данные обоих подтомов @_bak и @home_bak выглядят нормально. Потыкал по директориям, пооткрывал файлы - все ок. Правда, в процесее выдавало несколько сообщений вида:
We seem to be looping a lot on /some/file/name, do you want to keep going on ? (y/N/a):
Отвечал стандартное N. Сообщение выдавало только для кеша и файловол лога, думаю, это совершенно некритично.
Теперь как минимум, есть возможность попытаться отформатировать раздел, создать вручную подтома и все скопировать, если btrfs check все испортит.