Как мне исправить btrfs? [закрыто]

Я просмотрел списки рассылки и, наконец, попал на btrfsстраницу Ubuntu , и у меня осталось ощущение, что по- btrfs прежнему нет полной утилиты исправления (как указано на их домашней странице ). Несмотря на то, что несколько месяцев назад он был установлен по умолчанию для Oracle Linux и включен во многие дистрибутивы.

Итак, вместо этого есть ли где-нибудь руководство по устранению неполадок о том, как это исправить btrfs?

Если это не удастся, будет ли копирование моих резервных копий поверх моей FS исправлено? (При удалении снимков, если это необходимо для места? Или для удаления повреждений?) Стоит ли вместо этого попытаться вернуться к предыдущему снимку, а затем восстановить отсутствующие файлы из резервной копии? Или восстановить отсутствующие файлы из моих снимков @ и @home?

Примечание : это общий вопрос. Я намеренно опустил мои точные проблемы FS (на данный момент); Я хочу найти общий / канонический рабочий процесс и руководство по устранению неполадок.

(Хорошо, хорошо - вот некоторые больше деталей;)) :

Я выключился во время зависания, и поэтому у меня была нестабильность системы. Система будет загружаться и работать некоторое время, пока не запишет достаточно данных и не зависнет. В прошлый раз я только что открыл Thunderbird. Это требует более жесткого сброса и, возможно, большего количества коррупции. sudo btrfsck /dev/sda1колеблется между несколькими ошибками - часто впервые в форме

root 338 inode 7861227 errors 1000
root 338 inode 7904568 errors 1000
root 338 inode 7955174 errors 400
found 46242054144 bytes used err is 1
total csum bytes: 43112400
total tree bytes: 2074640384
total fs tree bytes: 1889853440
btree space waste bytes: 547680627
file data blocks allocated: 110756974592
 referenced 68393684992
Btrfs Btrfs v0.19

оооо, теперь это становится очень фруктовым (я только ожидал увидеть parent transid verify failedздесь ...)

parent transid verify failed on 14266105856 wanted 464223 found 464221
parent transid verify failed on 14266105856 wanted 464223 found 464221
Extent back ref already exists for 14261530624 parent 0 root 256 
leaf parent key incorrect 14261751808
bad block 14261751808
Extent back ref already exists for 66455355392 parent 0 root 2 
Extent back ref already exists for 66455257088 parent 0 root 2 
Extent back ref already exists for 14257274880 parent 0 root 2 
block 14262571008 rec extent_item_refs 2, passed 2
block 14262575104 rec extent_item_refs 1, passed 1
block 14262579200 rec extent_item_refs 1, passed 1
Extent back ref already exists for 14262579200 parent 0 root 257 
leaf 14263906304 items 50 free space 132 generation 464224 owner 2
fs uuid 7d049403-cf6e-4b52-a624-32051e1f5b2a
chunk uuid be6f8f93-320c-4465-85d6-f53907698c32
item 0 key (14263341056 EXTENT_ITEM 4096) itemoff 3944 itemsize 51
    extent refs 1 gen 464168 flags 2
    tree block key (8332576 1 0) level 0
    tree block backref root 257
item 1 key (14263345152 EXTENT_ITEM 4096) itemoff 3893 itemsize 51
    extent refs 1 gen 464168 flags 2
    tree block key (8332586 c 8332543) level 0
    tree block backref root 257
failed to find block number 14263525376

(Конечно, все это обобщено; я никогда не хотел ошеломлять вас этими деталями :))

И теперь мое окончательное исполнение оставляет меня со знакомым:

parent transid verify failed on 14265458688 wanted 464230 found 464221
parent transid verify failed on 14265458688 wanted 464230 found 464221
parent transid verify failed on 14265458688 wanted 464230 found 464223
btrfsck: root-tree.c:46: btrfs_find_last_root: Assertion `!(path->slots[0] == 0)' failed.

, включая необязательную случайную ошибку в конце. О, счастливая радость. Обратите внимание, что они verify failedменяются по мере записи данных на диск.

Еще одна случайная ошибка:

btrfsck: disk-io.c:412: find_and_setup_root: Assertion `!(!root->node)' failed.

Чтобы помочь с ответом:

Не удалось выполнить родительскую проверку на 14265458688, разыскивается 464230, найдено 464221

Может быть исправлено с помощью:

$ btrfs-zero-log DEVICE

ПРИМЕЧАНИЕ: данные могут быть потеряны! Сначала попробуйте и установите с:

$ mount -t btrfs -o recovery,nospace_cache,clear_cache DEVICE MOUNTPOINT

Если не могу смонтировать данные, такие как «bad fs»:

$ btrfs restore DEVICE DIRECTORY_TO_DUMP_DATA_TO

Вот настоящее, хотя и трудное для понимания, электронное письмо, которое я отправил, чтобы разъяснить его решение. Надеюсь, вы сможете разобрать это загадочное объяснение:

выдержка из электронной почты

Re: Вопрос: Как я могу восстановить этот раздел? (не удалось найти логический $ hugenum len 4096)

Хьюго Миллс carfax.org.uk> пишет:

В понедельник, 26 августа 2013 года в 13:10:54 -0600 Крис Мерфи написал:

26 августа 2013 года, в 11:41, Ник Ли nickle.es> написал:

Несколько дней назад на IRC обсуждался вопрос о том, что проблема с блоком корней дерева, скорее всего, является результатом проблемы с самим диском или чанк-дерева / логических отображений. Я запустил восстановление чанка, просмотрел найденные ошибки и нажал кнопку записи. (Если это не удастся, я собираюсь запустить что-то Photorec, потеря организации в качестве побочного эффекта.)

Я могу написать что-нибудь более ясное после того, как мой полет приземлится завтра, если хочешь.

Мне просто любопытно, когда использовать различные методы: -o recovery, btrfsck, chunk-recovery, zero log.

Предположим, что у вас нет сбоя физического устройства (это другой набор инструментов - mount -odegraded, btrfs dev del missing).

Первое, что нужно сделать, это взять btrfs-image -c9 -t4 файловой системы и сохранить копию выходных данных, чтобы показать josef. :)

Затем начните с -orecovery и -oro, восстановление для чего угодно.

Если это не помогло, то посмотрите в dmesg ошибки, относящиеся к дереву журналов - если оно повреждено и не может быть прочитано (или вызывает сбой), используйте btrfs-zero-log.

Если есть проблемы с деревом чанков - единственное, что я недавно видел, сообщало что-то вроде «не удается сопоставить адрес» - тогда может пригодиться чанк-восстановление.

После этого, вероятно, стоит попробовать btrfsck. Если опции -s1, -s2, -s3 имеют успех, то btrfs-select-super поможет, заменив суперблок на работающий. Если это не будет полезно, вернитесь к btrfsck --repair.

Наконец, btrfsck --repair --init-экстент-дерево может быть необходимо, если есть поврежденное дерево экстентов. Наконец, если у вас есть искажения в контрольных суммах, есть --init-csum-tree.

Hugo.