Теорія операційної системи

:: Меню ::

Головна
Представлення даних в обчислювальних системах
Машинні мови
Завантаження програм
Управління оперативною пам'яттю
Сегментна і сторінкова віртуальна пам'ять
Комп'ютер і зовнішні події
Паралелізм з точки зору програміста
Реалізація багатозадачності на однопроцесорних комп'ютерах  
Зовнішні пристрої
Драйвери зовнішніх пристроїв
Файлові системи
Безпека
Огляд архітектури сучасних ОС

:: Друзі ::

Карта сайту
 

:: Статистика ::

 

 

 

 

 

аппарат для сахарной ваты купить, а4

Відновлення ФС після збою

Найчастіше суперблок нестійких ФС містить прапор flirty ("брудний"), що сигналізує про те, що ФС, можливо, потребує відновлення. Цей прапор скидається при нормальному размонтірованії ФС і встановлюється при її монтуванні або при першій модифікації після монтування. Таким чином, якщо ОС загинула, не встигнувши размонтіровать свої дискові томи, після перезавантаження на цих томах dirty-флаг буде встановлений, що і стане сигналом необхідності лагодження.
Відновлення полягає в тому, що система перевіряє простір, виділений всім файлам. При цьому повинні виконуватися наступні вимоги.

  1. 1. Кожен запис в каталозі повинен мати правильний формат і містити осмислені дані. Наприклад, якщо запис помічений як вільна, вона не повинна посилатися на дані, помічені як що належать файлу, або на і під. Не у всіх ФС можна виявити помилки такого типа.
  2. 2. Кожен блок або кластер диска повинні належати не більш, ніж одному файлу. Блоки, що належать одночасно двом або більш файлам, є дуже серйозною помилкою. На практиці це означав що дані у всіх цих файлах (в кращому разі — у всіх, крім того запис в який був останнім) безнадійно зіпсовані. Найчастіше програма відновлення в цій ситуації вимагає втручання попь зователя, з тим щоб вирішити, які з файлів слід видалити або обре зать по місцю пересічення. Інколи для кожного з файлів створюється до пія "спільного" блоку, але і в цьому випадку користувачеві все одно потрібно визначити, які з файлів зіпсовані.

Практично все ФС при виділенні блоку спочатку видаляють його із списку вільних і лише потім віддають файлу, тому при "звичайних" збоях перехрещення файлів виникнути може лише як наслідок відкладеного запису у поєднанні з сортуванням запитів. Виникнення таких помилок зазвичай сигналізує або про помилку в самому файловому менеджерові, або про апаратні збої на диску, або про те, що структури ФС були модифіковані в обхід файлового менеджера. Наприклад, в ДОС це може бути ознакою вірусної активності.

  1. 3. Кожному файлу має бути виділене простір, відповідний його довжині. Якщо файлу виділено більше блоків, чим потрібний, зайві блоки позначаються як вільні. Якщо менше, файл коротшає. Можливо, в укорочених файлах частина даних виявляється втрачена.
  2. 4. Всі блоки, що не належать файлам, мають бути помічені, як вільні. Відповідний тип помилок — втрачені блоки — найбільш частий результат системних збоїв як у файловій системі FAT, так і в складніших файлових системах. Самі по собі помилки цього типа відносно нешкідливі.

Зазвичай програма відновлення не позначає втрачені блоки як вільні, а виділяє з них безперервні ланцюжки і створює з цих ланцюжків файли. Наприклад, в Os/2 програма відновлення намагається знайти у втрачених блоках файлові записи, а потім створює заслання на знайдені таким чином файли в каталозі \FOUND.XXX. У DOS ці файли поміщаються в кореневий каталог ФС під іменами FILEXXXX.CHK (замість ХХХХ підставляється номер). Передбачається, що користувач переглядає всі такі файли і визначає, чи не містить якийсь з них коштовній інформації, наприклад, кінця насильницький укороченого файлу.
У системах сімейства Unix існує декілька специфічних помилок, пов'язаних з інодамі.

  • Інод, внутрішній лічильник заслань якого не відповідає реальній кількості заслань з каталогів. Ця проблема може виникати при системному збої у момент видалення існуючого зв'язку або створення повий. Вона вирішується корекцією внутрішнього лічильника інода. Після цього можна виявити наступні дві помилки.
  • Інод, що не має жодного заслання, але і не помічений як вільний — сирота (orphan) (мал. 11.20). Заслання на такій і під створюється в каталозі lost+foiind;
  • Інод з некульовою кількістю заслань з каталогів, але помічений як вільний. Найчастіше це свідчить про псування самого каталога. Зазвичай заслання на такій інод віддаляються.

Мал. 11.20. Инод-сирота

Ручне відновлення файлової системи
У деяких особливо важких випадках програма відновлення виявляється не в змозі впоратися з аварією, що сталася, і адміністраторові системи доводиться братися за дисковий редактор.
В процесі експлуатації системи SCO Open Desktop 4.0 у автора неодноразово виникала необхідність виконувати холодне перезавантаження без нормального размонтірованія файлових систем. Одне з таких перезавантажень привело до катастрофи.
Дискова підсистема машини складалася з кеширующего контроллера дискового масиву. Контроллер активно використовував відкладений запис, що, мабуть, і послужило причиною катастрофи. Під час планового резервного копіювання драйвер лентопротяжки "впав в ступор" і заблокував процес копіювання (механізм виникнення цієї аварії детальніше обговорювався в разд. Обмін даними з призначеним для користувача процесом). Із-за наявності завислого процесу опинилося неможливе размонтіровать файлову систему, і машина була перезавантажена натисненням кнопки RESET без виконання нормального закриття, у тому числі і без виконання операції закриття драйвера дискового масиву, яка повинна була скинути на диски вміст буферів контроллера.
Після перезавантаження система автоматично запустила програму відновлення файлової системи fsck (File System CHECK), яка видала радісне повідомлення: DUP in inode 2. Для незнайомих з системними утилітами Unix н обходжений сказати, що DUP означає помилку перехрещення файлів, а інп~ 2— це інод кореневого каталога ФС. Таким чином, коренева директорія дискового тому об'ємом близько 2 Гбайт опинилася зіпсована. При цьому череня ляющєє більшість каталогів і файлів були не зачеплені катаклізмом опинилися недоступні. Програма відновлення не могла перенести ссилк на відповідні іноди в каталог lost+found, оскільки заслання на нього такж йде з кореневого каталога.
Ситуація представлялася безвихідною. Катастрофа посилювалася тим, що сталася вона під час резервного копіювання, а остання "хороша" копія була зроблена неділю тому. Велику частину призначених для користувача даних можна було б відновити, але серед втрачених файлів опинився журнальний файл сервера СУБД ORACLE (сама база даних знаходилася в іншому розділі диска). Довелося зайнятися відновленням ФС з використанням дискового редактора, мотивуючи це тим, що "втрачати все одно вже нічого" Власне, у відновленні ФС брали участь дві люди — автор і штатний адміністратор системи. Автор у жодному випадку не хоче створити у читача враження, що план відновлення був розроблений особисто їм — це був плід спільних зусиль, проб і помилок.
Редагування системних даних "складних" ФС з використанням простого шістнадцятиричного дискового редактора є украй невдячним заняттям. Є підстави стверджувати, що це взагалі неможливо. В усякому разі, авторові не доводилося чути про успіх такого підприємства. На щастя, системи сімейства Unix надають для редагування ФС спеціальну програму fsdb (File System Debugger— відладчик файлової системи). Призначеним для користувача інтерфейсом ця програма нагадує програму DEBUG.COM, що поставляється з MS DOS; головною її перевагою є те, що вона "знайома" з основними поняттями файлової системи. Так, наприклад, fsdb дозволяє проглянути вміст 10-го логічного блоку файлу з інодом 23 456, виділити фізичний блок 567 345 файлу з інодом 2 або помітити інод 1245 як вільний.
Перша спроба відновлення полягала в тому, що ми видалили той інод, з яким перехрещувався кореневий каталог, змонтували том командою "безумовного" монтування (яка дозволяла вмонтовувати пошкоджені томи), створили командою mkdir каталог lost+found і знов запустили fsck. Спроба завершилася крахом. Беда була в тому, що, як виявилось, кореневий каталог перетинався також і із списком вільних блоків, тобто створення каталога, а потім його розширення командою f sck знову приводило до псування кореневого каталога і завдання зводилося до попереднього.
Таким чином, нам необхідно було або виправити уручну список вільних блоків, або знайти спосіб створити директорію lost+found без звернень до цього списку. Додаткова складність полягала в тому, що з каталогом lost+found не пов'язане фіксованого інода, а визначити інод старого lost+found не представлялося можливим.
Ми вирішили не зв'язуватися з відновленням списку вільних блоків. Замість цього ми проглянули лістинг останньої "правильної" резервної копії, знайшли там непотрібний порожній каталог і приєднали його до кореневого під назвою lost+found. Після цього нам залишалося лише сподіватися на те, що новостворювані f sck-ссылки на файли не приведуть до необхідності подовжити наш lost+found. На щастя, цього не сталося: всі нащадки кореневого каталога благополучно отримали імена в lost+found. По суті, ФС прийшла в придатний для читання достаток, залишалося лише правильно визначити імена знайдених каталогів. Це також опинилося відносно нескладним завданням: велика частина каталогів на томі складалася з домашніх каталогів користувачів і їх імена можна було відновити на підставі того, КТО ці каталоги належали. Для останніх каталогів ім'я достатнє легкий визначалося після зіставлення їх вмісту з лістингом резервної копії.

У багато сучасних ОС реалізовані стійкі до збоїв файлові системи: jfs в AIX і Os/2 v4.5, Veritas в Unixware, NTFS в Windows Nt/2000/xp. Практично всі такі ФС засновані на механізмі, який по-англійськи називається intention logging (реєстрація намірів).

 

:: Реклама ::

 

:: Посилання ::


 

 

 


Copyright © Kivik, 2017