(РЕШЕНО) Сломался BTRFS

vasek
возможно ли подключение/восстановление из снапшотов, если системе не монтируется???
ну если подтом снапшотов с системой на одном разделе, то не думаю опять упрется в эти КС. Ну если только у бтрфс есть опция позволяющая эту проверку КС выключить при монтирование. А ее как видимо нету.
Дополняю свой пост к выше сказаному. Даже наверное можно все на одном харде делать, но только подтом для снапшотов на другой раздел вынести (типо как бут для ext необязательная фича) ну тип когда щелкается монтируется этот раздел, когда отщелкалось отмонтирование.
nafanja, а это пробовали?Тыц. Глядишь поможет. Да как вам помочь хочется, но осознаешь свою без беспомощность перед btrfs. Да и сам я с таким не сталкивался ибо у меня нетбук ну а там какие могут перебои в питание если есть аккумулятор. Сталкивался только с липовыми подтомами, которые я не создавал. Якобы это все SystemD делает.

P.S Спасибо за костыль воодушевляет стабильность.
nafanja
btrfs даже под убунтой падает (((
ubuntu@ubuntu:~$ sudo btrfs rescue chunk-recover /dev/sda3
А не пробовал запустить btrfs check /dev/… с разными опциями, например (и другими)
--init-csum-tree           create a new CRC tree
--init-extent-tree          create a new extent tree
--check-data-csum      verify checksums of data blocks

EDIT 1 - и последний вопрос - а не пробовал посмотреть вывод dump-superblock, dump-tree? - в смысле что то выведет или будет ругань
- btrfs inspect-internal dump-super /dev/…
- btrfs inspect-internal dump-tree /dev/…
Если chunk нарушен/не доступен, то возможно достать файлы только по сигнатуре - это утилиты foremost, scalpel или вручную
If the chunk tree is unavailable, only raw recovery based on file signatures is possible.
Ошибки не исчезают с опытом - они просто умнеют
nafanja, желаю вам удачи в восстановлении данных. Отписывайтесь если какие-нибудь сдвиги будут. Я буду за темой следить.
Мне очень эта тема интересна. Эх блин самая фишка btrfs улетает из выше сказанного экономия первичных разделов и снапшоты когда они действительно нужны.
Shama_comp
в восстановлении данных
Для ознакомления с btrfs создал образ ФС btrfs размером 1G, в нем 3 файла с расширениями txt, jpg, odt.
Уже который день пытаюсь извлечь эти 3 файла, используя The Sleuth Kit for btrfs - и ни хрена не получается, не могу понять заложенный там принцип указания offset.
Сегодня забил на это и использовал старый ручной способ по сигнатуре - на извлечение файла jpg ушло меньше получаса.
Так что если прижмет, то важные файлы с большой вероятностью вытащить можно и ручками, имея только образ (dump) системы или для вытаскивания большого количества файлов использовать утилиты, умеющие работать с сигнатурой.

EDIT 1 - но, имхо, если структура btrfs нарушена (не возможно построить дерево), то бесполезна и The Sleuth Kit и приходим к выводу, уже отмеченному выше, восстановление файлов возможно только по сигнатуре (старый хакерский способ).

PS - в части сообщения "parent transid verify failed on … wanted … found …"
Вот что об этом написано в исходниках
we can't consider a given block up to date unless the transid of the block matches the transid in the parent node's pointer.  This is how we detect blocks that either didn't get written at all or got written in the wrong place.

И еще понравилось одно высказывание из doc btrfs
dead metadata = dead volume with no chance of recovery
Ошибки не исчезают с опытом - они просто умнеют
Уточнение в части сообщений
parent transid verify failed on … wanted … found …
Смысл, насколько я понимаю, такой: эти сообщения возникают тогда, когда операция записи была прервана, например, в результате отключения питания, что привело к нарушению целостности данных - имеются незавершенные транзакции.
И, как пишут, btrfs в этой ситуации не дает подключить диск с разрешением на запись и советуют отбросить незавершенные транзакции, используя btrfs rescue zero-log.
Вот что об использовании этой команды пишется в man btrfs rescue 8
Эта команда очистит дерево журнала файловой системы. Это может исправить определенный набор проблем, когда монтирование файловой системы не удается из-за несоответствий журнала.

И все-таки неплохо бы проверить и состояние superblock. Если он не выводится командой, то можно посмотреть в ручную - 0-ой (primary) и 1-ый - и сравнить выводы (2-х блоков думаю достаточно).
Посмотреть можно так (можно прямо с дампа)
0 - hexdump -C -s 65536 -n 4096 /file
1 - hexdump -C -s 67108864 -n 4096 /file
Будут не сопадать только первые строки - это checksum
Ошибки не исчезают с опытом - они просто умнеют
nafanja, уже отмечал, что меня в файловой системе интересует вопрос извлечения файлов из неработающей системы, а так как сейчас занялся осваиванием btrfs, то чисто технический вопрос - в твоем случае имеется возможность получить вывод btrfs inspect-internal dump-tree /… ?
Сегодня разбирался с этим выводом и понял, что используя его можно в ручную извлечь отдельные файлы (что проделал и практически). В этом выводе имеется и название файлов, их размер и смещение.
Ошибки не исчезают с опытом - они просто умнеют
короче, я это как то сделал.
система пока не грузится, но раздел монтируется... и вроде данные на месте.
что то делалось очень долго, много-много часов... задолбался ждать и остановил процесс, перегрузился в винду и был приятно удивлен тому что винда увидела раздел...
под лайф убунтой он тоже монтируется.
сохраню нужные данные и попробую повторить.

vasek
btrfs inspect-internal dump-tree
да, это работает, по крайней мере показывает корневую структуру раздела... сами названия файлов я не увидел, наверное нужно было подождать, там очень большой вывод...
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
наверное нужно было подождать, там очень большой вывод…
Да там вывод большой. И чем больше файлов, тем больше вывод. Наверное лучше делать вывод в файл.
Привожу в качестве примера часть моего вывода
file tree key (256 ROOT_ITEM 0)
 item 15 key (259 INODE_REF 256) itemoff 15102 itemsize 22
		index 4 namelen 12 name: image.jpg
	item 16 key (259 EXTENT_DATA 0) itemoff 15049 itemsize 53
		generation 11 type 1 (regular)
		extent data disk byte 13660160 nr 200704
		extent data offset 0 nr 200704 ram 200704
		extent compression 0 (none)
И видим
- название - image.ipg
- размер - 200704
- смещение - 13660160

1. Смотрим сам файл image.jpg (1-ая и последняя строчки)
hexdump -C -n 16 /mnt/loop/TEST/image.jpg
00000000  ff d8 ff e0 00 10 4a 46  49 46 00 01 01 01 00 60  |......JFIF.....`|
…………………...
00030640  50 6c 03 b9 fc e8 a2 b3  70 8f 63 5b b3 ff d9     |Pl......p.c[...|

2. Смотрим по данным вывода btrfs inspect-internal dump-tree
hexdump -C -s 13660160 -n 200704 ~/btrfs-image
00d07000  ff d8 ff e0 00 10 4a 46  49 46 00 01 01 01 00 60  |......JFIF.....`|
……………………….
00d37640  50 6c 03 b9 fc e8 a2 b3  70 8f 63 5b b3 ff d9 00  |Pl......p.c[....|
Выкинул из последнего вывода нулевые строки
00d37650  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00d38000
И как видим - полное соответствие
Конечно, в большой системе это громоздкий вывод, НО если вытащить несколько важных файлов, то можно и помучаться … безусловно, должен быть опыт работы.

PS - просьба потом отписаться, что делал.
Ошибки не исчезают с опытом - они просто умнеют
Смотрим сам файл image.jpg (1-ая и последняя строчки)
hexdump -C -n 16 /mnt/loop/TEST/image.jpg
И что каждый файл вытаскивать?
 
Зарегистрироваться или войдите чтобы оставить сообщение.