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

:: Меню ::

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

:: Друзі ::

Карта сайту
 

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

 

 

 

 

 

На сайте http://www.dendy-druk.com замовити банер львів. | Наша компания бронедвери низкие цены

Стійкість до збоїв живлення

Насправді, неочікуване припинення роботи з ФС може статися не лише при збої живлення, але і в наступних ситуаціях:

  • витяганні носія з дисковода (детальніше про цьому див. далі);
  • натисненні кнопки RESET нетерплячим користувачем;
  • фатальному апаратному збої;
  • апаратному збої, який сам по собі не був фатальним, але система не змогла правильно відновитися, що привело до її руйнування;
  • руйнуванні системи із-за чисто програмних проблем.

На практиці часто складно провести кордони між трьома останніми типами збоїв. Як приклад можна привести проблему, описану в разд. Обмін даними з призначеним для користувача процесом. У системах класу ДОС остання причина виникає дуже часто, тому в таких системах можна використовувати лише стійкі збоям ФС.
У системах класу ОС "спонтанні" зависання відбуваються набагато рідше Система, що зависає по незрозумілих або неусувних причинах разів в декілька днів, вважається малопридатною для серйозного використання а що робить це раз на місяць — підозріло ненадійною. Тому в таких системах можна дозволити собі розкіш використовувати нестійкі до збоїв ФС. Тим більше що такі системи, як правило, володіють вищою продуктивністю, ніж стійкі ФС.
До того ж перед виключенням системи, інтегрованої в мережу, необхідно повідомити всіх клієнтів і всі сервери про роз'єднання. Лише чисто клієнтська машина може бути вимкнена з мережі без проблем. Тому на мережевих серверах у будь-якому випадку необхідна процедура закриття системи (shutdown). То чом би не покласти на цю процедуру ще і функцію размонтірованія ФС?
У системах же реального часу, які по роду роботи можуть часто і несподівано перезапускатися, наприклад, при відладці драйверів або програм, що здійснюють доступ до апаратури, прагнуть використовувати стійкі до збоїв ФС.
Хоча перша з перерахованих вище причин — витягання носія з дисковода — не є "збоєм" навіть в найширшому сенсі цього слова, з точки зору ФС вона мало чим відрізняється від збою. Тому на носіях, що видаляються, таких, як дискети, можна використовувати лише стійкі ФС.
Цікавий альтернативний підхід використовується в комп'ютерах Macintosh і деяких робочих станціях. В цих машин дисковод не має кнопки для витягання дискети. Виштовхування дискети здійснюється програмно, подачею відповідної команди дисководу. Перед подачею такої команди ОС може виконати нормальне размонтірованіє ФС на диску, що видаляється.
У вузькому сенсі слова "стійкість" означає лише те, що ФС після аварійного перезавантаження не обов'язково потребує відновлення. Такі ФС забезпечують цілісність власних структур даних в разі збою, але, взагалі кажучи, не гарантують цілісності призначених для користувача даних у файлах.
Потрібно відзначити, що навіть якщо ФС вважається в цьому сенсі стійкої, деякі збої для неї можуть бути небезпечні. Наприклад, якщо запустити команду DISKOPT на "стійкій" файловій системі FAT і у відповідний момент натискувати кнопку RESET то значна частина даних на диску може бути назавжди втрачена.
З іншого боку, можна говорити про стійкість в тому сенсі, що у ФС після збою гарантована цілісність призначених для користувача даних. Досить простого аналізу для того, щоб переконатися, що таку гарантію не можна забезпечити на рівні ФС; забезпечення подібної цілісності накладає серйозні обмеження і на програми, що працюють з даними, а інколи виявляється просто неможливим.
Характерний і дуже простий приклад: архіватор Infozip працює над створенням архіву. Програма сформувала заголовок файлу, упакувала і записала на диск близько 50% даних, і у цей момент стався збій. У zip-архивах каталог знаходиться в кінці архівного файлу і записується туди після завершення упаковки всіх даних. Обрізаний у випадковому місці zip-файл не містить каталога і тому, безумовно, є безнадійно зіпсованим. Тому при серйозному обговоренні проблеми стійкості до збоїв говорять не про гарантію цілісності призначених для користувача даних, а про зменшення вірогідності їх псування.
Підтримка цілісності структур ФС зазвичай набагато важливіше, ніж цілісність недописаних у момент збою призначених для користувача даних. Річ у тому, що якщо при збої виявляється зіпсований файл, що створювався, це достатньо неприємний; якщо ж опиниться зіпсована файлова система, у гіршому разі це може привести до втрати всіх даних на диску, тобто до катастрофи. Тому зазвичай забезпеченню цілісності ФС при збоях приділяється значно більше уваги.
Згадувана вище "природжена" стійкість до збоїв файлової системи FAT пояснюється тим, що в цій ФС видалення блоку із списку вільних і виділення його файлу проводиться однією дією — модифікацією елементу FAT (мал. 11.16). Тому якщо під час цієї процедури станеться збій або дискета буде вийнята з дисковода, то нічого страшного не трапиться: просто вийде файл, якому виділено на один блок більше, ніж його довжина, записана в каталозі. При стиранні цього файлу всі його блоки будуть помічені як вільні, тому шкоди практично немає.

Мал. 11.16. Модифікація FAT

Потрібно відзначити, що при активному використанні відкладеного запису FAT і родинні ФС втрачають цю перевагу. Відкладений запис FAT є єдиним способом добитися хоч скільки-небудь прийнятній продуктивності від ФС з 32-бітовим FAT. Тому, хоча Novell Netware і використовує ФС, засновану на 32-бітовій FAT, після аварійного перезавантаження ця система вимушена запускати програму аварійною становлення дискових томів. Аналогічним чином поводиться і Fat3? Якщо ж система зберігає в одному місці список або карту вільних блоків, а у іншому місці списки блоків, виділених кожному файлу (мал. 11.17) як це роблять HPFS або ФС систем сімейства Unix, то при перериванні операції виділення місця в непідходящий момент можуть або втрачатися блоки (якщо ми спочатку видаляємо блок із списку свободних— мал. 11.18) або виходити блоки, які одночасно вважаються і вільними, і зайнятими (якщо ми спочатку виділяємо блок файлу).
Перша ситуація досить неприємна, друга ж просто недопустима: перший же файл, створений після перевизова системи, "перехрещуватиметься" із зіпсованим (мал. 11.19). Тому все ОС, що використовують файлові системи такого типа (системи сімейства Unix, Os/2, Windows NT і т. д.), після аварійного перезавантаження насамперед перевіряють своп ФС відповідною програмою відновлення.

Мал. 11.17. Модифікація структур даних складної ФС

Мал. 11.18. Втрачений блок

Мал. 11.19. Пересічні файли

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

 

:: Реклама ::

 

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


 

 

 


Copyright © Kivik, 2017