Reviews / articles about OS/2 |
Operating systems: ArcaOS, eComStation, IBM OS/2 Warp |
|
|
|
|
DATE: 2003-07-28 15:03:28 AUTHOR: Pavel Shtemenko
ВступлениеДанная статья не утвержает, что JFS "падает" каждый час, она лишь претендует на то, "что делать" (c) если это случилось. По моему личному убеждению, абсолютно надежного нет ничего, это относится и к FS и к законам термодинамики. И опять таки, автор настаивает на том что знать о потерях информации и сделать предупреждающие мероприятия - это разные вещи. Далее. По глубокому убеждению автора (научная литература насчет FS отсуствует как класс) надежность FS складывается из:
Можно привести кучу графиков и кучу формул, но обычно даже для самого продвинутого в случае неисправности интересует одно - "что делать" (c) Чернышевский
Часть 1Вопросы почему может разрушится структура JFS я здесь рассматривать не буду, (за такие обзоры кандидатская как минимум). Будем констатировать, что "произошло". Штатный случай, chkdsk не проходит, говорит о каких-то ошибках, том не монтируется. "Что делать?" (c). Самое первое это не впадать в панику и не кричать - "В нижнее место такую ос, поставлю другую". Могу вас разочаровать, в другой ос вероятность возникновения того же, как минимум такая же. ;-) Итак, на вашем диске есть сектора и в них информация хранится, хотя системе она и недоступна. Осознали? Успокоились? То что, на самый крайний случай можно применить дисковый редактор и чью-то мать тоже поняли? Замечательно. Далее и рассмотрим как облегчить нелегкий труд добывания данных с полудохлых носителей информации записанных в формате JFS.
Часть 2Итак, имеем (не важно по каким причинам) не читаемый ос том и "Что делать?" (c) Первое, конечно, попытаться всевозможными системными способами его восстановить до читаемости (исключая форматирование конечно). Обычно это не получается, следующий путь это применение "легкой артиллерии" - isj [скачать], что делает это утилита? Она заставляет chkdsk при старте "не проверять" диск, соотвественно JFS его замонтирует и вы под угрозой трапа из-за разрушенной структуры, можете хотя бы часть переписать. Такую операцию можно повторять пока вы не наткнетесь на кусок, на котором происходит однозначный трап ос. Итак наткнулись, как гласят законы Мерфи, там обязательно будут находится наиболее важные для вас данные. Жалко, печально, но не смертельно (вспомните о запасе в виде дискогого редактора и вам станет легче). Итак на "легкой артиллерии" мы исчерпали все. Сразу замечу, у всех есть ошибки, в chkdsk в том числе, потому ,забегая вперед, можно еще попытаться ISJ поставить флаг "не проверять" и не перегружаясь запустить: Jrescuer N: /R Если все удастся, то вы получите читаемый системой JFS том без применения "тяжелой артиллерии" (насчет возможных трапов из за разрушенной структуры я промолчу).
Часть 3Постулируем, до применения дискогого редактора, осталось совсем немного, но... Вовремя вспоминает, что isj и ос это еще не все! Есть еще утилита Jrescuer [скачать]; Вытаскиваем на свет и рассматриваем. Возможности - поддержка системой JFS не нужна - нужна только буква диска (хотя ее автор клянется, как только ее купит первый линухойд надобность в буквах отпадет) и ujfs.dll (пока) от любой версии JFS. Чешем репу и вкладываем на дискету первую подвернувшуюся под руки ujfs.dll , хотя это все можно запускать откуда угодно, лишь бы в путях была ujfs.dll. Дальше начинается то, что "нельзя описать словами" (c) Дюна, утилита не для слабонервных, для слабонервных предусмотрен весьма облегченный режим: Jrescuer N: где N - буква диска По этой команде она будет вытягивать с JFS все начиная с корневого каталога в текущей откуда запущена. Все вытянулось? Замечательно, но возможны варианты прямого попадания BAD SECTOR в самые нужные места (про законы Мерфи уже читали?). Это тоже не повод для паники (вспомните о дисковом редакторе), мы берем и распечатываем корневой каталог командой: Jrescuer N: /D=1 Видим листинг, выдаваемый в виде: InodeNumber0 Name0 Flag0 ...... InodeNumberM NameM FlagM
где, Далее, мы вибираем ту директорию, в которой находятся интересующие данные, и громко не таясь говорим: Jrescuer N: /I=InodeNumber На что он ответит вытаскиванием всех файлов и из этой директории включая поддиректории тоже. Все это есстественно происходит в текущий каталог откуда был запущен Jrescuer. Произошло? Превосходно! А если нет? Вспомним в очередной раз о дисковом редакторе и попытаемся через: Jrescuer N: /D=n где n - уровень погружения в поддиректории Обнаружить где ж происходит облом. Обнаружили что в каталоге \foo\foo1\foo2...fooM Jrescuer останавливается. Это тоже не повод для паники (вспомните о дисковом редакторе), Нельзя вытянуть весь каталог? Отлично, но зато можно вытянуть отдельные файлы из этого каталога. Для этого предусмотрен ключ G. Итак, напрягая и без того истекающую битами память, вспоминаете, нам надо добыть файл \foo\foo1...fooM\fileWithSize0 , посему радостно сообщаете: Jrescuer N: /G=\foo\foo1...fooQ\fileWithSize0 и если это возможно, вы ,после непродолжительной работы Jrescuer, его увидите, но, памятуя законы Мерфи, ессено вы его не получите, тогда у вас остается только два варианта:
ПослесловиеТем кто очень хочет добыть данные, следует изучить структуру JFS, тем кто ничего не понял, поменяйте "дисковый редактор" на "белая обезъяна" и прочтите снова. А в общем... Jrescuer писался на "костях", то есть тогда когда была в наличии погибшая JFS и хозяин оной мог вытерпеть все мои испытания на ней. Лично у меня JFS погибла только один раз, во время спасения и родилась ISJ.
Благодарности
Маленький FAQ
Q: Бывают случаи когда не помогает ISJ?
Q: Бывают случаи когда не помогает Jrescuer?
Q: Возможно ли все эти утилиты применить к JFS/Linux
JRescuer - это продукт eCo Software, (c) Павел Штеменко.
Лицензированная версия JRescuer поставляется
в
составе операционной
системы eComStation/Rus.
Комментарии:
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
(C) OS2.GURU 2001-2021
