LINUX.ORG.RU
Форум — Admin  

восстановление XFS


0

0

Дано:
4 диска, собраны в raid 1 и потом отданы в lvm

создано несколько разделов xfs на lvm

Однажды, в студёную зимнюю пору... после жесткого ребута один из разделов xfs умирает.

mdadm говорит, что все ОК, остальные разделы посредством xfs_repair восстановили свою работоспособность.

а данный при xfs_repair с любыми параметрами, хоть -L. хоть -d сваливается на 6-й фазе с ошибкой

disconnected inode 537803581, moving to lost+found
disconnected inode 537803582, moving to lost+found

fatal error — name create failed in lost+found (117), filesystem may be out of space

Увеличил swap, ситуация не изменилась, ругается на ту-же ноду

Если запустить xfs_ncheck /dev/hdd/DISK3 (проблемный диск)
то зависает на

bad magic # 0x49414254 in btbno block 0/10869
bad btree nrecs (254, min=255, max=510) in btbno block 0/11064
bad btree nrecs (254, min=255, max=510) in btbno block 0/11533
bad magic # 0x58443242 in btcnt block 0/157



если обнулять ноду
xfs_db -x -c 'inode 537803582' -c 'write core.nextents 0' -c 'write core.size 0' /dev/hdd/DISK3

ситуация не меняется

кусок вывода xfs_repair также

block (0,392354) already used, state 2

block (0,392355) already used, state 2
bad magic # 0x58443242 in btcnt block 0/157
expected level 0 got 296 in btcnt block 0/157
bcnt freespace btree block claimed (state 1), agno 0, bno 157, suspect 0
inode btree block claimed (state 7), agno 0, bno 10869, suspect 0
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
imap claims a free inode 4445976 is in use, correcting imap and clearing inode
- agno = 1
- agno = 2
- agno = 3
- agno = 4


Куда копать?

Куда копать?

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

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

zgen ★★★★★
()

Нет UPS, т.е. машина домашняя?

Я для домашней машины отказался от raid1 по нескольким причинам, в том числе и вот такие поломки. Разбил свой рейд1 и делаю на второй диск копию rsync'ом. Так как второй диск все остальное время находится в режиме readonly, никакие сбои ему особенно не страшны.

Чего и вам желаю, а ext#, reiser(fs), xfs, ?fs одинаково не любят жесткие падения системы.

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

есть UPS, но сгорело много что, включая UPS :( поэтому падение было жестким rsync не подходит, так как там террабайты. снапшоты lvm конечно, как вариант.

pirojok
() автор топика
Ответ на: комментарий от sdio

> Нет UPS, т.е. машина домашняя?

Причем здесь UPS? Если он есть - то он защитит, может быть, от внезапного пропадания питания. Но это далеко не единственная причина жесткого ребута. При этом ТС вообще ничего насчет питания не говорил.

Чего и вам желаю, а ext#, reiser(fs), xfs, ?fs одинаково не любят жесткие падения системы

Надо ли это понимать так, что в линуксе с файловыми системами все настолько уныло?

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

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

mikki
()

Куда копать?

Копать в сторону бэкапа.

bad magic # 0x49414254 и bad magic # 0x58443242 выглядят похоже на MAGIC-последовательности (по крайней мере вторая в точности):

xfs_ag.h:#define	XFS_AGF_MAGIC	0x58414746	/* 'XAGF' */
xfs_ag.h:#define	XFS_AGI_MAGIC	0x58414749	/* 'XAGI' */
xfs_alloc_btree.h:#define	XFS_ABTB_MAGIC	0x41425442	/* 'ABTB' for bno tree */
xfs_alloc_btree.h:#define	XFS_ABTC_MAGIC	0x41425443	/* 'ABTC' for cnt tree */
xfs_dir2_block.h:#define	XFS_DIR2_BLOCK_MAGIC	0x58443242	/* XD2B: for one block dirs */
xfs_dir2_data.h:#define	XFS_DIR2_DATA_MAGIC	0x58443244	/* XD2D: for multiblock dirs */
xfs_dir2_node.h:#define	XFS_DIR2_FREE_MAGIC	0x58443246	/* XD2F */
xfs_sb.h:#define	XFS_SB_MAGIC		0x58465342	/* 'XFSB' *

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

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

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

Более современные интегрированные системы типа btrfs и ZFS сделали бы эту дурную работу (проверку каждого подзеркала) за тебя автоматом, и за счет избыточности и CoW либо вообще бы этот сбой не заметили, или бы заметили и исправили автоматом, либо позволили легко восстановиться к предыдущему состоянию (по крайней мере, в случае с ZFS).

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

> Более современные интегрированные системы типа btrfs и ZFS сделали бы эту дурную работу

Ну да, догнали бы и ещё раз сделали :)

anonymous
()

попробуй использовать NTFS. Для него есть очень крутые утилиты для восстановления всего.

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

>> Более современные интегрированные системы типа btrfs и ZFS сделали бы эту дурную работу

Ну да, догнали бы и ещё раз сделали :)

Сказать то что хотел?

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