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

:: Меню ::

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

:: Друзі ::

Карта сайту
 

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

 

 

 

 

 

Файлові системи з реєстрацією намірів

Термін, винесений в заголовок цього підрозділу, є дослівною калькою (можливо, не дуже вдалою) англомовного терміну intention logging. У російській мові, на жаль, ще немає загальноприйнятого терміну для цього поняття.
Ідея журналів реєстрації намірів прийшла з систем управління базами даних. У СУБД часто виникає завдання внесення погоджених змін в декілька різних структур даних. Наприклад, банківська система перекладає мільйон доларів з одного рахунку на іншій. СУБД віднімає 1 000 000 з суми на першому рахунку, потім намагається додати ту ж величину до другого рахунку і у цей момент відбувається збій.
Для СУБД цей приклад виглядає дуже тривіально, але ми вибрали його тому, що він схожий на ситуацію у файловій системі: у якому б порядку не проводилися дії з перенесення об'єкту з однієї структури в іншу, збій в невдалий момент приводить до украй неприємної ситуації. У СУБД ця проблема була усвідомлена як гостра дуже давно — адже мільйон доларів завжди був набагато дорожчий за один сектор на диску.
Задовільне вирішення проблеми полягає в наступному.

  • По-перше, всі погоджені зміни в СУБД організовуються в блоки, звані транзакціями (transaction). Кожна транзакція здійснюється як неділима (атомарна) операція, під час якої жодні інші операції над змінними даними не дозволені.
  • По-друге, кожна транзакція здійснюється в три етапи (мал. 11.21)
    • Система записує в спеціальний журнальний файл, що ж вона з біраєтся робити.
    • Якщо запис в журнал був успішним, система виконує транзакцію.
    • Якщо транзакція завершилася нормально, система позначає в журналі, що намір був успішно реалізований.


Мал. 11.21. Виконання транзакції з реєстрацією намірів

Журнал часто називають журналом реєстрації намірів (intention log) що дуже добре відображає суть справи, бо в цей журнал записуються саме наміри (intentions).
При використанні відкладеного запису транзакція вважається повністю завершеною, лише коли останній блок змінених даних буде фізично записаний на диск. При цьому в системі зазвичай одночасно існуватиме декілька незавершених транзакцій (мал. Ii.22). Легко зрозуміти, що при операціях з самим журналом відкладений запис вообше не можна використовувати.

Мал. 11.22. Черга транзакцій, що виконуються

Якщо стався збій системи, після перезавантаження запускається програма відновлення бази даних (мал. 11.23). Ця програма переглядає кінець журналу.

  • Якщо вона бачить там зіпсований запис, то ігнорує її: збій стався під час запису в журнал.
  • Якщо всі записи помічені як успішно виконані транзакції, то збій стався між транзакціями: нічого особливо страшного не трапилося; в усякому разі, нічого виправляти не треба.
  • Якщо знайдений запис, який відзначає почату, але невиконану транзакцію, то збій стався під час цієї транзакції. Це найбільш неприємна ситуація, але журнал містить досить інформації для того, щоб або відновити достаток бази даних до початку транзакції (виконати відкіт назад (rollback)), або ж доробити зміни, що передбачалися.

Потрібно відзначити, що дані, необхідні для виконання відкоту, можуть мати великий об'єм. Фактично це копія всіх даних, що піддаються Зміні в ході транзакції. Багато СУБД, такі як ORACLE, зберігають ці дані не в самому журналі, а в спеціальній області даних, званій сегмент відкоту (rollback segment).

Мал. 11.23. Журнал транзакцій після збою

Детальніша інформація про роботу журналів намірів в базах даних може бути знайдена у відповідній літературі [Дейт 1999, Дейт 1988). Необхідно лише відзначити, що книги і навіть фірмова документація по простих СУБД типа dbase або Foxpro тут не допоможуть, оскільки ці пакети не містять засобів реєстрації в журналі.
Ідея журналу намірів досить природний переноситься в програму управління файловою системою. Але тут виникає цікаве питання -что ж вважати транзакцією: лише операції по розподілу простору на диску або також всі операції по зміні даних?
Перший варіант простіше в реалізації і робить менший вплив на продуктивність; зате він гарантує лише цілісність самій ФС, але не може гарантувати цілісності призначених для користувача даних, якщо збій станеться у момент запису у файл.
Другий варіант вимагає виділення сегменту відкоту і сильно уповільнює роботу. Дійсно, адже тепер дані пишуться на диск двічі: спочатку в сегмент відкоту, а потім в сам файл. Зате він істотно знижує вірогідність псування призначених для користувача даних.
ряд сучасних ФС з реєстрацією намірів підтримують обидва режими роботи і надають вибір між цими варіантами адміністраторові системи. Наприклад, у файлової системи vxfs плі Veritas, що входить в пакет Unixware (версія Unix Svr4, що поставляється фірмою Novell), існує дві версії. Одна версія, що поставляється разом з системою за умовчанням, включає в транзакцію лише системні дані. Інша, "advanced", версія, яка поставляється за окремі гроші, здійснює реєстрацію намірів як для системних, так і для призначених для користувача даних.

Журнали намірів в Veritas
У Veritas 2 дисковий том розбитий на області, звані групами циліндрів (термін, успадкований з FFS— файлової системи BSD Unix). Кожна група циліндрів має свою карту вільних блоків, ділянку динамічної таблиці інодов і журнал намірів (мал. 11.24). Журнал намірів організований у вигляді кільцевого буфера записів про транзакції. У журнал пишуться дані лише про транзакції над інодамі, що належать до цієї групи циліндрів. При цьому в кожній групі може виконуватися одночасно декілька транзакцій і закінченням транзакції вважається фізичне завершення запису модифікованих даних. Кількість транзакцій, що одночасно виконуються, обмежена об'ємом журналу, але оскільки кожна група циліндрів має свій журнал, це обмеження не грає великої ролі.

Мал. 11.24. Групи циліндрів і журнали транзакцій Veritas

 

:: Реклама ::

 

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


 

 

 


Copyright © Kivik, 2017