Как восстанавливать Ext3

[bdimych]

PII 266 MHz, 128 Mb
Western Digital 20 Gb
-первый раздел primary swap 500Мб
-остальное boot primary Linux ext3, если не ошибаюсь блоки по 1 Кб
MOPSLinux 5.0

Отошел на час, возвращаюсь - висит, на клавиатуру не реагирует. Ну я ресет делаю. Ядро грузится но во время монтирования получается panic. Загрузился с MOPS cd 1, fsck, начинает писать ошибки. Сначала я думаю - сам все исправит и нажимаю вводы, но постепенно понимаю что дело плохо т.к. ошибки валятся непрерывно и не кончаются.

Я еще ни разу не сталкивался с тем что надо восстанавливать целый диск с линуксом видимо серьезно поврежденный. Сейчас я диск вынул и подключил к рабочему компьютеру. Посоветуйте пожалуйста дальнейшие действия.

И на будущее можно ли как то повысить надежность файловой системы в linux какими то настройками? При установке MOPS несколько месяцев назад я помню у меня были проблемы такого же порядка что вообще не работает именно из-за файловой системы, но тогда было все просто - поставил заново и все, а сейчас уже есть много настроек и данные. Есть ощущение что windows менее проблемная именно в смысле файловой системы?

[Juliette]

Для начала можно попробовать так:

fsck.ext3 -y /dev/hdx$

(подставляете ваше значение.)
Потом есть ещё хорошая утилита TestDisk, качаем отсюда: http://www.cgsecurity.org/wiki/TestDisk_Download
ЗЫ - и насчёт проблемности-непроблемности, это лучше не подначивать народ. Используйте то, что у вас лично не проблемное. Лично у меня за 5 лет сидения на ext3 в разных дистрах она ни разу не падала вообще (включая перебои со светом и жёсткие ресеты)

[bdimych]

На самом деле сравнивать подначивать я не хотел. За все примерно лет 10 использования компьютеров вообще я пнримерно раз 10 же видел серьезные поломки дисков. На линукс я вот сейчас и пытаюсь перейти и за меньше чем полгода наблюдаю две серьезные поломки на одном компе. Рабочий комп у меня тоже под тем же MOPS и тоже полгода и ни разу не слетал и переживал отключения питания. Рабочий - пень3, нерабочий - пень2.

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

ЗЫ
Я почитал про ext3 - это система по умолчанию Debian а Debian это вообще по стабильности считается чуть ли не эталон. Т.е. мне странно - что у меня такое было что удалось ее повалить.

[Juliette]

man hdparm - утилита для настройки парметров жёстких дисков, к большинству подойдёт с такими опциями:

hdparm -qm8 -qu1 -qc1 -qd1 /dev/hdx

ну и вы всё-таки сделали, что я вам посоветовала?
а также - вы уверены в целостности своего железа?
ну и вообще - с какими параметрами монтируете? (etc/fstab в студию)
зы - извините, сразу не увидела, что fsck вы уже пробовали...

[alv]

нерабочий - пень2.

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

Перед падением я заметил что комп тарахтел диском довольно интенсивно.

Я почитал про ext3 - это система по умолчанию Debian

Это родная файловая система Linux и по умолчанию в очень многих дистрах

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

Я бы на Вашем месте не обольшался - скорее всего, Вам не удалось ее повалить. Просто аппаратный сбой.
А в настольных условиях повалить любую файловую систему Линукса можно только одним способом:
dd if=/dev/curve_hands of=/dev/ass
Хотя, возможно, тут задействуется не столько устройсво curve_hands, сколько bad_head

[bdimych]

Это нерабочий диск подключенный к пню3 - вроде читается вообще без ошибок

Код: Выделить всё

badblocks -s -v /dev/hdb2
  Checking blocks 0 to 19062792
  Checking for bad blocks (read-only test): done                        792
  Pass completed, 0 bad blocks found.

Это нерабочий диск подключенный к пню3 поиск суперблока

Код: Выделить всё

TestDisk 6.6, Data Recovery Utility, February 2007
  Disk /dev/hdb - 20 GB / 18 GiB - CHS 38792 16 63
       Partition                  Start        End    Size in sectors
    Linux                  969   0  1 38791  15 63   38125584
  superblock 0, blocksize=4096

Попытка что то починить как написано в доках к testdisk

Код:

fsck -b0 -B4096 /dev/hdb2 fsck 1.38 (30-Jun-2005) e2fsck 1.38 (30-Jun-2005) Note: if several inode or block bitmap blocks or part of the inode table require relocation, you may wish to try running e2fsck with the '-b 8200' option first. The problem may lie only with the primary block group descriptors, and the backup block group descriptors may be OK. Block bitmap for group 1 is not in group. (block 0) Relocate<y>? yes Inode bitmap for group 1 is not in group. (block 0) Relocate<y>? yes Inode table for group 1 is not in group. (block 0) WARNING: SEVERE DATA LOSS POSSIBLE. Relocate<y>? yes Block bitmap for group 513 is not in group. (block 0) Relocate<y>? yes /dev/hdb2 contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Inode 65594, i_blocks is 8376, should be 8384. Fix<y>?

.....
и дальше примерно то же самое что и было - немерено ошибок полезло

Это для сравнения я посмотрел диск рабочего пня3

Код: Выделить всё

TestDisk 6.6, Data Recovery Utility, February 2007
  Disk /dev/hdc - 20 GB / 18 GiB - CHS 2438 255 63
       Partition                  Start        End    Size in sectors
    Linux                   61   0  1  2437 254 62   38186504
  superblock 0, blocksize=1024
  superblock 8193, blocksize=1024
  superblock 24577, blocksize=1024
  superblock 40961, blocksize=1024
  superblock 57345, blocksize=1024

Получается что все суперблоки потерялись что ли ?
еще не все потеряно

Код: Выделить всё

debugfs:  ls
   2  (12) .    2  (12) ..    11  (20) lost+found    18612225  (12) var
   11075585  (12) dev    6356993  (12) bin    3211265  (12) boot
   17793025  (12) etc    3375105  (12) home    11829250  (16) opt
   17367041  (12) lib    98305  (12) mnt    12353537  (12) proc
   65537  (12) root    11599873  (12) sbin    3932161  (12) sys
   2228225  (12) tmp    14221313  (3880) usr

А что с ней (т.е. с debugfs) дальше делать я еще не понял - прочел про успешное использование http://www.linuxquestions.org/questions/sh...006#post1782006 надо как то журнал попробовать удалить что ли?
Пень2 должен стать необслуживаемым устройством 24/7 (все уже было подобрано и настроено и вот такая кака!). Вопрос самый точный: можно ли и как повысить надежность linux именно для работы в необслуживаемом устройстве с жестким диском. Например отключить буферизацию записи или увеличить число резервных копий суперблока (Size in sectors=38186504 а максимальный суперблок всего то 57345). Или например использовать ext2 т.к. http://www.linuxquestions.org/questions/sh...006#post1782006

Подредактировала в смысле кода, не забываем его использовать, господа! (J)

[bdimych]

Удалось восстановить данные с помощью debugfs ... rdump

Код:

root@mops5:~# debugfs /dev/hdb2 debugfs 1.38 (30-Jun-2005) debugfs: ls 2 (12) . 2 (12) .. 11 (20) lost+found 18612225 (12) var 11075585 (12) dev 6356993 (12) bin 3211265 (12) boot 17793025 (12) etc 3375105 (12) home 11829250 (16) opt 17367041 (12) lib 98305 (12) mnt 12353537 (12) proc 65537 (12) root 11599873 (12) sbin 3932161 (12) sys 2228225 (12) tmp 14221313 (3880) usr debugfs: cd root debugfs: ls 65537 (12) . 2 (12) .. 65538 (24) loadlin16c.txt 65539 (24) loadlin16c.zip 163881 (12) .mc 163883 (12) .qt 66422 (28) .gtk_qt_engine_rc 66423 (20) .gtkrc-2.0 66561 (24) .serverauth.3687 66559 (24) .bash_history 133290 (16) .kde 66565 (24) .fonts.cache-1 133352 (16) Desktop 655362 (16) .links 66570 (28) .Xauthority 66563 (16) .lesshst 66575 (32) .ICEauthority 229379 (28) .thumbnails 133380 (16) .local 133396 (16) .mcop 133583 (80) .xine 688148 (16) .gxine 11665418 (16) .mailcap 655383 (16) .cpan 655368 (12) .vlc 688186 (16) .gnupg 721202 (36) .emacs.d 688840 (24) .openoffice.org2 11665422 (24) .serverauth.3958 66425 (16) .viminfo 11665419 (20) .esd_auth 753668 (16) .wine 721398 (20) .kpackage 950491 (20) .macromedia 819692 (28) .mozilla 11665426 (24) .recently-used 950514 (16) .screen 11665421 (16) .kderc 819711 (20) .fullcircle 11665430 (32) .mcoprc 655797 (16) .xmms 1015818 (16) .TeXmacs 656060 (28) .subversion 66574 (80) .serverauth.3922 11665428 (20) .xcompmgrrc 11665429 (3068) .fonts.conf debugfs: rdump Desktop /tmp debugfs: q root@mops5:~# ls /tmp/Desktop 6220M_E_V2.0_90412.doc motion/ svnrepo/ vlc/ heap/ MyComputer.desktop TeXmacs-1.0.6.9-i486-1McD.tgz work/ kaffeine.desktop Network.desktop tightvnc-1.3.8-i486-1kjz.tgz xawtv-3.95/ krecord-1.16.tar.gz npp.4.0.2.bin.zip trash.desktop xawtv-3.95.tar.gz root@mops5:~#

Но удаление журнала не помогло получить монтируемую систему

Код:

bash-3.1# tune2fs -O ^has_journal /dev/hdb2 tune2fs 1.38 (30-Jun-2005) bash-3.1# e2fsck -f /dev/hdb2 e2fsck 1.38 (30-Jun-2005) Group descriptors look bad... trying backup blocks... Block bitmap for group 1 is not in group. (block 0) Relocate<y>? no Inode bitmap for group 1 is not in group. (block 0) Relocate<y>? no Inode table for group 1 is not in group. (block 0) WARNING: SEVERE DATA LOSS POSSIBLE. Relocate<y>? no Block bitmap for group 513 is not in group. (block 0) Relocate<y>? cancelled! Inode bitmap for group 513 is not in group. (block 0) Relocate<y>? cancelled! Inode table for group 513 is not in group. (block 0) WARNING: SEVERE DATA LOSS POSSIBLE. Relocate<y>? cancelled! ну как и раньше ... bash-3.1# mount -t ext2 /dev/hdb2 /mnt/new mount: wrong fs type, bad option, bad superblock on /dev/hdb2, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so bash-3.1#

Т.е. debugfs всё видит вообще без проблем а mount чего же ? Может как то пересоздать суперблок?

[bdimych]

Сравнение ext2 и ext3
http://www.xakep.ru/magazine/xA/086/108/2.asp

Другая серьезная проблема - целостность журнала и агрессивный характер fsck, неадекватным образом реагирующий на некоторые виды повреждений. В последнее время появилось множество сообщений о некачественных SATA-контроллерах, приводящих к различным сбоям, затрагивающим журнал и метаданные. Основная структура тома остается практически неповрежденной (так, маленькая трещинка), и ручным восстановлением его еще можно спасти, но запуск fsck грохает раздел окончательно, причем ext3 страдает намного сильнее, чем ext2. Вероятно, так происходит потому, что в журнале оказывается мусор, а fsck пытается его интерпретировать «правильным» образом, вот и... Конечно, поклонники ext3 могут сказать, что нечего ее гонять на кривом железе, нужно купить себе нормальный SCSI-контроллер и отказаться от АТА. Все это верно и совершенно правильно, но все-таки от сбоев железа никто не застрахован, поэтому при «обкатке» нового оборудования все-таки лучше использовать ext2 и только затем переходить на ext3.

[alv]

Сравнение ext2 и ext3
http://www.xakep.ru/magazine/xA/086/108/2.asp

Бред какой-то...
Что за "некачественные SATA-контроллеры"?
Где это "множество сообщений"?
И какой здравомыслящий человек а наши дни будет покупать "себе нормальный SCSI-контроллер и отказаться от АТА"?
Очередная страшила от автора "Гибели Титаника".
А надежную гарантию восстановления данных может дать только их регулярное резервное копирование. Вне зависимости от ОС и файловой системы.


Так, вы мне это прекратите. Уважаемый bdimych, вы опять "не хотели" провоцировать? (J)

[ddc]

Бред какой-то...

По-моему, ты зря это принимаешь так близко к сердцу. Журнал ][akep известен большим объёмом бреда, и эта статья едва ли выбивается из общей картины.

[bdimych]

Почему mount и fsck не работают хотя на диске осталось достаточно информации чтобы без проблем правильно читать файловую систему что доказывает debugfs?

[BaBL]

Бред какой-то...
Что за "некачественные SATA-контроллеры"?
Где это "множество сообщений"?
И какой здравомыслящий человек а наши дни будет покупать "себе нормальный SCSI-контроллер и отказаться от АТА"?
Очередная страшила от автора "Гибели Титаника".
А надежную гарантию восстановления данных может дать только их регулярное резервное копирование. Вне зависимости от ОС и файловой системы.
Так, вы мне это прекратите. Уважаемый bdimych, вы опять "не хотели" провоцировать? (J)

судя по:

Другая серьезная проблема - целостность журнала и агрессивный характер fsck, неадекватным образом реагирующий на некоторые виды повреждений. В последнее время появилось множество сообщений о некачественных SATA-контроллерах, приводящих к различным сбоям, затрагивающим журнал и метаданные. Основная структура тома остается практически неповрежденной (так, маленькая трещинка), и ручным восстановлением его еще можно спасти, но запуск fsck грохает раздел окончательно, причем ext3 страдает намного сильнее, чем ext2

может быть речь идет о ядреной баге ext3 с версии 2.6.5 до 2.6.17? которая приводила к порче данных при data=ordered и спасением было только writeback до появления патчей? Просто, наверное, автор статьи плавает в теме и банально пролистал недельные новости, выплеснув пачку понравившихся тезисов.

А надежную гарантию восстановления данных может дать только их регулярное резервное копирование. Вне зависимости от ОС и файловой системы.

а ext3cow? =)

[ddc]

bdimych
Признайтесь честно, Вы - троль?

Почему mount и fsck не работают хотя на диске осталось достаточно информации чтобы без проблем правильно читать файловую систему что доказывает debugfs?

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

BaBL

А надежную гарантию восстановления данных может дать только их регулярное резервное копирование. Вне зависимости от ОС и файловой системы.

а ext3cow? =)

По сути это есть ext3 с регулярным (при использовании cron) резервным копированием.

[bdimych]

может быть речь идет о ядреной баге ext3 с версии 2.6.5 до 2.6.17

у меня там была 2.6.19.1

Признайтесь честно, Вы - троль?

???

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

ну вообще то я надеялся на какие то рекомендации

Трудно было угадать, да?

[ddc]

ну вообще то я надеялся на какие то рекомендации

Трудно было угадать, да?

Учитывая, что вопрос был:

Почему mount и fsck не работают хотя на диске осталось достаточно информации чтобы без проблем правильно читать файловую систему что доказывает debugfs?

Да, непросто было.

[Juliette]

Дискуссия плавно переместилась сюда
Какую файловую систему выбрать для необслуживаемого устройства 24/7
Закрываю.

EDIT - открываю на пробу по просьбе автора темы. Буде флейм продолжится - закрою насовсем.

[bdimych]

Можно ли и как восстановить всю фс ext2 если debugfs видит если не все то очень многие файлы, а fsck и mount не работают.