LINUX.ORG.RU

btrfs, после сбоя по питанию


0

1

Недавно собрал роутер/NAS, корень и файлопомойку поставил на btrfs, которая в свою очередь стоит в lvm с остальными разделами(ext2\ext4). Вчера вырубили свет, ИБП нет, после чего дебиан6 (39 ядро из сида) отказался монтировать корневую ФС.

Вот что говорит sysresccd:

root@sysresccd /root % mount -t btrfs -o compress=lzo /dev/mapper/nas-root /re 
mount: wrong fs type, bad option, bad superblock on /dev/mapper/nas-root,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

root@sysresccd /root % dmesg | tail
[ 3821.972350] parent transid verify failed on 3807195136 wanted 5412 found 5414
[ 3821.972364] parent transid verify failed on 3807195136 wanted 5412 found 5414
[ 3821.979182] btrfs: open_ctree failed
[ 6298.660270] device label root devid 1 transid 12174 /dev/mapper/nas-root
[ 6298.660657] btrfs: use lzo compression
[ 6298.662878] parent transid verify failed on 3807195136 wanted 5412 found 5414
[ 6298.663321] parent transid verify failed on 3807195136 wanted 5412 found 5414
[ 6298.663584] parent transid verify failed on 3807195136 wanted 5412 found 5414
[ 6298.663595] parent transid verify failed on 3807195136 wanted 5412 found 5414
[ 6298.669180] btrfs: open_ctree failed

root@sysresccd /root % btrfsck /dev/nas/root 
parent transid verify failed on 3807195136 wanted 5412 found 5414
parent transid verify failed on 3807195136 wanted 5412 found 5414
parent transid verify failed on 3807195136 wanted 5412 found 5414
btrfsck: disk-io.c:416: find_and_setup_root: Assertion `!(!root->node)' failed.
zsh: abort      btrfsck /dev/nas/root

root@sysresccd /root % btrfsck /dev/nas/media 
couldn't open because of unsupported option features (8).
btrfsck: disk-io.c:682: open_ctree_fd: Assertion `!(1)' failed.
zsh: abort      btrfsck /dev/nas/media

/dev/mapper/nas-media - монтируется
[ 7006.674870] device label nas-misc devid 1 transid 16104 /dev/mapper/nas-media
[ 7006.675381] btrfs: use lzo compression

ФС монтировались с опцией -o compress=lzo.

Как с наименьшем вредом можно восстановить фс?


Дождаться, пока допилят fsck.btrfs.

Вот вам и COW, вот вам и новейшая ФС, вот вам и правота Шишкина. Посижу-ка я на ext4.

post-factum ★★★★★ ()

ставь btrfsck из git - все что могу посоветовать. За сохранность информации после такой проверки естественно ответственности не несу...

Pinkbyte ★★★★★ ()
Ответ на: комментарий от post-factum

Сегодня только хотел всю систему перенести на эту фс, теперь не буду, хорошо хоть решил до вечера подождать

deterok ★★★★★ ()
Ответ на: комментарий от deterok

Тоже руки чешутся (уже давно), вот только мне мозгов хватает поглядывать за состоянием, пока ни дисковый формат не стабилизировали ни уж тем более инструментарий. Т.е. сия фс пока годится только в роли игрушки.

erfea ★★★★★ ()
Ответ на: комментарий от post-factum

Лучше на интервью с Поповым... Его мнение будет авторитетнее ИМХО.

ЗЫ:

В ноябре 2007 года (12-23 ноября 2007, или всё же в феврале [4]?) происходит двухдневная встреча разработчиков файловых систем, посвящённая вопросу создания файловой системы нового поколения для Linux (next generation filesystem, NGFS). На встрече присутствуют инженеры компаний , принимающие участие в разработке файловых систем ext2, ext4, OCFS2, lustre, btrfs, AdvFS, Reiser4 и XFS. В результате было решено [5], что:

Linux файловая система нового поколения необходима;

Файловая система Криса Масона, называемая btrfs, наиболее хорошо подходит на роль такой файловой системы;

Разработка файловой системы нового поколения и переход на неё будут осуществляться продолжительное время, и на этом этапе в качестве основной файловой системы стоит использовать ext4.

(взято с xgu)

Шишкин умнее «Oracle, IBM, Intel, HP и Red Hat»?!

erfea ★★★★★ ()
Ответ на: комментарий от xorik

Лучше бы прикрутили сжатие и снапшоты к ext4, чем велосипеды городить

Костыли лучше велосипедов, безусловно!!! :D

erfea ★★★★★ ()
Ответ на: комментарий от post-factum

> Дождаться, пока допилят fsck.btrfs.

Не стоит. Вместо того, чтобы заниматься делом - написанием и тестированием собственно файловой системы, чуваки заняты пилением btrfsck и тестированием fsck. У нее нет шансов, нужно забыть о ней и выбирать что-то другое.

Вот вам и COW, вот вам и новейшая ФС, вот вам и правота Шишкина.

COW и новейшая тут ни при чем. Нет нормальной организации процесса, никто толком не занимается тестированием, полагаясь на полчища леммингов.. Во времена примитивной ext2 так еще можно было делать, сегодня - нет.

anonymous ()
Ответ на: комментарий от post-factum

Я просил дургое. Нельзя было ее спроектировать так же, как у санок - ZFS нельзя убить отключением питания. Ее состояние всегда консистентно. Ну за исключеним одного случая - когда запись блока на жесткий прервалась в середине, и это был блок самого верхнего уровня

namezys ★★★★ ()
Ответ на: комментарий от post-factum

А тогда как этого добиться? или знаменитый unix way дает о себе знать, и компоненты из-за сверхнизкой связаности не могут согласнованно работать?

namezys ★★★★ ()
Ответ на: комментарий от namezys

Как-как… никак. Это не юникс-вей виноват, тот же reiserfs или ext4 не страдают такими заболеваниями. Это обыкновенная безалаберность.

post-factum ★★★★★ ()
Ответ на: комментарий от xorik

Всё, что приставлено с боку есть по определению костыль, запрошенная фича не была предусмотренна дизайном изначально, хотя слышал, что таки сделают.

erfea ★★★★★ ()
Ответ на: комментарий от post-factum

Хм. вообще журналируемые ФС чисто теоретически повреждаемые - ибо нужен откат, а значит нужны данныед для отката

namezys ★★★★ ()
Ответ на: комментарий от namezys

> Почему в ZFS такое невозможно by design?

Сначала тебе следовало бы доказать, что в ZFS такое невоэможно, потом - что оно невозможно by design.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Сначала тебе следовало бы...

Так, Джеф Бонвик всё уже доказал. Что непонятно?

iZEN ★★★★★ ()
Ответ на: комментарий от namezys

Согласен, конечно, но см. выше о том, что COW ещё ничего не значит.

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

Рекламы одного замечательного ультразвукового устройства (сначала это была панацея от всех болезней, потом стиральная машинка) тоже была научно аргументированна... Вот, только (очевидно) в отличии от тебя я ещё удосужился сам почитать про дизайн сабжа, оценить насколько это круто/хреново, почитать/попроводить реальные тесты (получить очень позитивные результаты даже для нормальной фс, а это ещё и не альфа и не бета, так имбрион). Можешь считать своего шишкина хоть всевышним создателем всего сущего, его мнение (докучи противоречещее спецам из ведущих компаний мира в IT) тянет максимум на имхо тела дрочещаго на свою reiser, интересную только ему самому, одному уголовничку да жалкой кучке фанатиков (без обид, просто так оно и есть).

erfea ★★★★★ ()
Ответ на: комментарий от erfea

> его мнение (докучи противоречещее спецам из ведущих компаний мира в IT

А в чем собственно противоречие, не могли бы показать? И покажите, пожалуйста, где «спецы ведущих IT компаний мира» обозначают условие балансировки btrfs? Аааа, не нашли? Интересно как-то получаются: крутые спецы из ведущих IT компаний мира что-то «балансируют», и не знают, как. Какой-то Шишкин спросил «а что вы подразумеваете под балансировкой», так на него зашикали: «Как можно? Убирайся! Её сам дядюшка Тс'о благословил!». И супер-fs-девелопер Крис Мейсон, как Дункан МакЛауд, вобравший в себя весь опыт наработок Неймсис, отвечая на мейлы того же Шишкина почему-то нещадно отрезал места в который заходила речь об условии балансировки btrfs.

Я скажу, в чём противоречие. Btrfs слишком сильно распиарили те самые ведущие IT-компании. Заморочили головы своим клиентам, которые теперь «кровь из носу» хотят Btrfs. И кто теперь возьмет на себя смелость сказать, что Btrfs - это поделие, шитое белыми нитками? Есть такая хорошая сказка, называется «Новый наряд Короля». Почитайте, очень советую...

anonymous ()

Всем спасибо хоть на «открывании газ», я почему и выбрал btrfs, посчитал что такой пиар + включение её по дефолту в федору, да ещё и её плюшки вполне годные. А ведь сегодня тоже хотел у ноута хоум перевести на неё..

Юникс-вей выхода не нашёл, буду переставлять с нуля.. Блин, и ведь снапшот тоже не успел сделать, на «потом» отложил...(

De1in ()
Ответ на: комментарий от De1in

И ведь самое интересное, в момент «падения», корневой раздел никак не должен был быть задействован, /tmp отдельно, /var отдельно, и на тот момент лился/смотрелся фильм из раздела /nas (btrfs, который всёже монтируется кое как)

De1in ()
Ответ на: комментарий от erfea

> Модульность и плагины есть хорошо, но не в драйвере фс же!

Сама VFS - это хороший пример модулей и плагинов. Если в процедуре name resolution попадаем в точку монтирования, то вызывается «плагин» соответствующей файловой системы. Внутри каждого такого плагина можно поступать аналогичным образом. Там уже, конечно, не происходит name resolution, но много всяких других вещей, для которых очень полезно устроить подобную «виртуализацию».

anonymous ()
Ответ на: комментарий от erfea

> На встрече присутствуют инженеры компаний , принимающие участие в разработке файловых систем ext2, ext4, OCFS2, lustre, btrfs, AdvFS, Reiser4

А можно огласить список разработчиков reiser4, которые были туда приглашены? Сплошные подтасовки, просто пипец какой-то... А потом удивляются, почему Btrfs не работает...

anonymous ()
Ответ на: комментарий от namezys

> Ну за исключеним одного случая - когда запись блока на жесткий прервалась в середине, и это был блок самого верхнего уровня

Не вижу ничего исключительного в это случае - предыдущее состояние все еще на диске и все еще ее консистентно. Если даже запись первого из уберблоков нового состояния прервалась на середине, его контрольная сумма будет недействительной, и при открытии пула при загрузке будет выбран его предшественник. Содержимое потеряной группы транзакций, которое записывалось асинхронно, естественно потеряется, но ведь гарантий про него никто и не давал. А то, что писалось синхронно - никуда не пропадет, ибо ZIL просто проиграют заново и всего делов.

Так что тебя или неправильно информировали, или ты что-то другое имел ввиду.

А кстати, кто-нибудь знает, как в btrfs меХанизм COW распространяется на уберблоки?

anonymous ()
Ответ на: комментарий от namezys

> Ну за исключеним одного случая - когда запись блока на жесткий прервалась в середине, и это был блок самого верхнего уровня

Не вижу ничего исключительного в это случае - предыдущее состояние все еще на диске и все еще ее консистентно. Если даже запись первого из уберблоков нового состояния прервалась на середине, его контрольная сумма будет недействительной, и при открытии пула при загрузке будет выбран его предшественник. Содержимое потеряной группы транзакций, которое записывалось асинхронно, естественно потеряется, но ведь гарантий про него никто и не давал. А то, что писалось синхронно - никуда не пропадет, ибо ZIL просто проиграют заново и всего делов.

Так что тебя или неправильно информировали, или ты что-то другое имел ввиду.

А кстати, кто-нибудь знает, как в btrfs меХанизм COW распространяется на уберблоки?

anonymous ()
Ответ на: комментарий от anonymous

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

namezys ★★★★ ()
Ответ на: комментарий от post-factum

Товагищ, ви злостный офтопщик. Лучше ка тему удгалите.

darkshvein ☆☆ ()
Ответ на: комментарий от anonymous

Сама идея записи вверх, когда не происходит изменение блока, а только запись новых (и удаление старых) хорошо, но не достаточно - когда нить мы достигнем конца

namezys ★★★★ ()
Ответ на: комментарий от anonymous

есть блок уровня А. Ты его записал. Далее надо внести изменения в уровнь Б. Ты внес. Далее надо вносить изменение в уровень В. И так далее. А уровни эти когда нибудь кончатся

namezys ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.