LINUX.ORG.RU
ФорумAdmin

Восстановление данных с ext3 (не монтируется раздел)


0

0

Всем привет и с наступающим новым годом!

Не хочет монтироваться рабочий (/home) ext3 раздел, данные с которого очень важны. Произошло это все после очередной перезагрузки системы (абсолютно корректной). Проверка фс (fsck -f /dev/hdX) ничего не дала, пишет, что все в порядке. Логи и все прочее приведены ниже.

Система, на которой все это произошло: slackware-10.2. Раздел создавался еще на slackware-10.1 либо более ранней версии. Сейчас пробую подцепить под FC8 (2.6.23.9-85.fc8). Везде используются/лись ядра 2.6.X. В каком состоянии диск, точно сказать не могу. Железу (и хард и комп) приблизительно года 4. Но остальные разделы монтируются, со второго грузиться linux.


# fdisk /dev/sdb -l

Диск /dev/sdb: 120.0 ГБ, 120033041920 байт
255 heads, 63 sectors/track, 14593 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Disk identifier: 0xeca8e20a

Устр-во Загр Начало Конец Блоки Id Система
/dev/sdb1 * 1 646 5188963+ b W95 FAT32
/dev/sdb2 647 1284 5124735 83 Linux
/dev/sdb3 1285 14593 106904542+ f W95 расшир. (LBA)
/dev/sdb5 1285 8933 61440561 b W95 FAT32
/dev/sdb6 8934 14593 45463918+ 83 Linux

Нужный раздел - sdb6, именно он и не монтируется.

При монтировании в лог сыпется:

EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting. Commit interval 5 seconds
EXT3-fs: recovery complete.
Assertion failure in cleanup_journal_tail() at fs/jbd/checkpoint.c:430: "blocknr != 0"
------------[ cut here ]------------
kernel BUG at fs/jbd/checkpoint.c:430!
invalid opcode: 0000 [#1] SMP
Modules linked in: autofs4 nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp ipt_REJECT iptable_filter ip_tables x_tables loop dm_mirror dm_multipath dm_mod ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_pcm nvidia(P)(U) snd_timer i2c_viapro snd_page_alloc snd_mpu401 via_ircc snd_mpu401_uart snd_rawmidi irda button snd_seq_device 8139cp i2c_core parport_pc snd 8139too ns558 crc_ccitt parport pcspkr mii tulip gameport soundcore sr_mod sg cdrom floppy pata_via ata_generic libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd
CPU: 0
EIP: 0060:[<f887ab85>] Tainted: P VLI
EFLAGS: 00210282 (2.6.23.9-85.fc8 #1)
EIP is at cleanup_journal_tail+0x85/0xe8 [jbd]
eax: 0000005a ebx: ef941400 ecx: 00200086 edx: 00200000
esi: 00000001 edi: 002799b6 ebp: ef941414 esp: e8d3dc84
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process mount (pid: 2744, ti=e8d3d000 task=efa04c20 task.ti=e8d3d000)
Stack: f887e57b f887d7dc f887e544 000001ae f887e758 ef941400 00000001 e8d1a400
f887cd6e ef941414 00000000 efa04c20 c043d495 e8d3dcb8 00000000 ef941000
ef941400 e8d1a400 ef941000 f88b0d2d 00001000 00000008 00ad8000 f88b35f7
Call Trace:
[<f887cd6e>] journal_flush+0x92/0x1fa [jbd]
[<c043d495>] autoremove_wake_function+0x0/0x35
[<f88b0d2d>] ext3_mark_recovery_complete+0x21/0x67 [ext3]
[<f88b35f7>] ext3_fill_super+0x127f/0x13b7 [ext3]
[<c04f6051>] snprintf+0x1f/0x22
[<c04b649a>] disk_name+0x79/0x83
[<c0483024>] get_sb_bdev+0xe0/0x11e
[<f88b0ba8>] ext3_get_sb+0x20/0x25 [ext3]
[<f88b2378>] ext3_fill_super+0x0/0x13b7 [ext3]
[<c0482af1>] vfs_kern_mount+0x83/0xfe
[<c0482bb6>] do_kern_mount+0x35/0xbb
[<c04946c1>] do_mount+0x5fb/0x65d
[<c04646c4>] filemap_fault+0x22c/0x391
[<c046f14f>] handle_mm_fault+0x76d/0x78b
[<c0489705>] link_path_walk+0xa9/0xb3
[<c0620652>] do_page_fault+0x2c0/0x5ef
[<c0466693>] __alloc_pages+0x64/0x2a2
[<c061f07a>] error_code+0x72/0x78
[<c049479a>] sys_mount+0x77/0xae
[<c040518a>] syscall_call+0x7/0xb
=======================
Code: 44 24 10 58 e7 87 f8 c7 44 24 0c ae 01 00 00 c7 44 24 08 44 e5 87 f8 c7 44 24 04 dc d7 87 f8 c7 04 24 7b e5 87 f8 e8 6e 33 bb c7 <0f> 0b eb fe 39 bb c0 00 00 00 75 0a 86 53 14 b8 01 00 00 00 eb
EIP: [<f887ab85>] cleanup_journal_tail+0x85/0xe8 [jbd] SS:ESP 0068:e8d3dc84


Под slackware выдается та же ошибка:
Assertion failure in cleanup_journal_tail() at fs/jbd/checkpoint.c
за исключением того, что вывод немного разный (подгружены разные модули и т.д.).

В fs/jbd/checkpoint.c не лазил, и не думаю, что это поможет. Тем более, что это проявляется как на 2.6.13 так и на 2.6.23.

Посоветуте плиз что делать?
Как лучше проверить сам хард на наличие аппаратных проблем? Что делать с ФС?

Заранее всем благодарен.

ps: тема продублирована на opennet.ru по ссылке:
http://www.opennet.ru/openforum/vsluhforumID1/78063.html

★★

Как ext2 этот раздел тоже не монтируется ? Раз выключение было нормальным стало быть никакие данные не потерялись, на журнал можно и забить.

spirit ★★★★★
()

Больше похоже на косяк в ядре а не в ФС. Я бы попробовал с live-cd загрузится и подмонтировать.

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

> Как ext2 этот раздел тоже не монтируется ?

спасиб огромное. Сам сразу не дагадался... Как ext2 монтирутется! Что делать с журналом - не знаю, но щас буду первым делом данные оттуда бекапить :) А то как раз перед тем как это произошло хотел было забекапить, но тут - закон подлости...

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

> Больше похоже на косяк в ядре а не в ФС. Я бы попробовал с live-cd загрузится и подмонтировать.

пробывал с разными ядрами под разными системами, поэтому, если и косяк в ядре, то до сегодняшенго времени (до 2.6.23.9)

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