а б в

Мал. 6.19. Майже повний блок покажчиків вільних блоків в пам'яті і три блоки покажчиків на диску (а); результат видалення трьохблокового файлу (б); альтернативна стратегія (в)

Існує метод, що дозволяє уникнути зайвих операцій введення-виводу. Він полягає в тому, що повний блок покажчиків розщеплюється на два. При цьому з ситуації на мал. 6.19, а замість ситуації на мал. 6.19, би ми переходимо до ситуації на мал. 6.19, ст. При заповненні блоку покажчиків в пам'яті цей блок записується на диск не у вигляді заповненого до кінця блоку, а як блок, заповнений наполовину, тобто записується, по суті, половина покажчиків блоку. У пам'яті залишається блок з іншими покажчиками, тобто також заповнений наполовину блок. Таким чином, блок покажчиків, що зберігається в оперативній пам'яті, максимально готів як до додавання в нього нових покажчиків, так і до звільнення тих, що зберігаються в нім.

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

Дискові квоти

Щоб не допустити захоплення користувачами занадто великих ділянок дискового простору, багато користувацькі операційні системи часто містять механізм надання дискових квот. Суть в тому, що адміністратор назначає кожному користувачеві максимальну долю файлів і блоків, а операційна система гарантує, що користувачі не перевищують виділених ним квот. Типовий механізм реалізації цієї ідеї описаний нижче.

Коли користувач відкриває файл, операційна система знаходить його атрибути і дискові адреси і поміщає їх в таблицю в оперативній пам'яті. Серед атрибутів знаходиться елемент, що повідомляє, хто є власником цього файлу. Будь-які збільшення розмірів файлу враховуватимуться в записі квоти для цього користувача.

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

Ця таблиця показана на мал. 6.20. Вона витягається з файлу квот, що зберігається на диску. Коли усі файли закриті, запис записується назад у файл.

Мал.6.20. Квоти враховуються для кожного користувача в таблиці квот

Коли в табл3иці відкритих файлів створюється новий елемент, в нього вставляється покажчик на запис квоти власника файлу. При кожному додаванні нового блоку до файлу загальна кількість блоків, що числиться за користувачем, збільшується і порівнюється з гнучким і жорстким лімітом. Гнучкий ліміт може бути перевищений, але жорсткий немає. Досягши жорсткого ліміту будь-яка спроба добавити блок до файлу завершуватиметься помилкою. Аналогічно перевіряється кількість файлів користувача.

Коли користувач намагається реєструватися в системі, операційна система прочитує його файл квот, перевіряючи, чи не перевищив користувач гнучкі межі по числу блоків або числу файлів. Якщо одна з меж перевищена, операційна система видає попередження, а лічильник попереджень, що залишилися, зменшується на одиницю. Коли лічильник попереджень досягає нуля, операційна система відмовляє користувачеві в реєстрації. Щоб знову отримає можливість входити в систему, користувачеві необхідно звернутися до системного адміністратора.

Таким чином, користувач може перевищити свої гнучкі ліміти, при вимозі, що перед виходом з системи він видалить зайві файли, що перевищують ці межі. Жорсткі ліміти перевищені бути не можуть.

Надійність файлової системи

Руйнування файлової системи часто виявляється великим лихом, чим нащадка комп'ютера. Якщо комп'ютер руйнується внаслідок пожежі, удару блискавки або користувач проллє чашку кави на клавіатуру, це неприємно, ремонт зажадає грошей, але зазвичай не заподіє багато клопоту. Недорогі персональні комп'ютери можна замінити протягом години, звернувшись до відповідного комерсанта. (Виняток становлять університети, в яких для пирдбання персональних комп'ютерів потрібно узгодження цього питання в трьох комітетах, отримання п'яти підписів і 90 днів очікування.)

У разі ж втрати файлової системи з вини апаратури, або програмного забезпечення, або щурів, що прогризли додаткові отвори в гнучких дисках, відновлення усієї інформації буде важким, вимагаючи багато часу, а часто і неможливою справою. Для користувачів, чиї програми, документи, файли клієнтів, рахунки, бази даних, маркетингові плани або інші дані загублені назавжди, наслідки можуть виявитися катастрофічними. Хоча операційна система не може захистити від фізичного знищення устаткування або носія, вона може допомогти зберегти інформацію. У цьому розділі ми розглянемо деякі питання, що стосуються захисту файлової системи від знищення.

Коли гнучкі диски покидають фабрику, їх якість, як правило, пречудово, але з часом на них можуть з'явитися дефектні блоки. У жорстких дисків дефектні блоки часто бувають із самого початку, оскільки виробництво жорстких дисків абсолютне без дефектних блоків занадто дорого. Як вже розповідалося в главі 5, дефектні блоки зазвичай контролер замінює спеціальні запасними блоками. Проте ця техніка не здатна захистити абсолютно від усіх можливих варіантів втрати інформації.

Резервні копії

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

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

Друга причина полягає в тому, що користувачі часто випадково видаляють файли, які пізніше виявляються потрібними. Ця проблема виникає так часто, що в системі Windows при звичайному видаленні файлу він насправді не видаляється, а поміщається в спеціальний каталог, званий сміттєвим кошиком, звідки його при необхідності нескладно вивудити назад. Резервні копії продовжують цей принцип далі, дозволяючи відновлювати з архівних стрічок файли, видалені багато днів і навіть тижнів назад.

Створення резервних копій займає багато часу і вимагає багато місця, по-цьому особливого значення при цьому набувають ефективність і зручність. По-перше, чи слід архівувати усю файлову систему або тільки її частину? Багато операційних систем зберігають двійкові файли в окремих каталогах. Ці файли не обов'язково архівувати, оскільки вони можуть бути переустановлені з CD - ROM виробника. Крім того, більшість систем мають каталог для тимчасових файлів. У їх архівації також немає необхідності. У системі UNIX усі спеціальні файли (пристроїв введення-виводу) зберігаються в каталозі /dev. Створювати резервну копію цього каталогу не лише непотрібно, але і небезпечно, оскільки програма архівації може назавжди повиснути, якщо спробує читати ці файли. Тому зазвичай створюються резервні копії окремих каталогів, а не усієї файлової системи.

По-друге, архівувати файли, що не змінилися з моменту останньої архівації, неефективно, тому на практиці застосовується ідея інкрементних резервних копій, або, як їх ще називають, інкрементних дампів. Проста форма інкрементної архівації полягає в тому, що повна резервна копія створюється, скажімо, раз на тиждень або раз на місяць, а щодня зберігаються тільки ті файли, які змінилися з моменту останньої повної архівації. Ще краще архівувати тільки ті файли, які змінилися з моменту останньої архівації. Така схема скорочує час створення резервних копій, але ускладнює процес відновлення, оскільки для цього треба спочатку відновити файли останньої повної архівації, а потім виконати ту ж процедуру з усіма інкрементними резервними копіями. Щоб спростити відновлення, часто застосовуються складніші схеми інкрементної архівації.

По-третє, оскільки об'єм даних, що архівуються, зазвичай дуже великий, бажано стискувати ці дані до запису на магнітну стрічку. Проте багато алгоритми стискування даних влаштовано так, що щонайменший дефект стрічки може привести до нечитабельності усього файлу або навіть усієї стрічки. Тому слід гарненько подумати, перш ніж приймати рішення про стискування даних, що архівуються.

По-четверте, створення резервної копії складно виконувати в активній файловій системі. Якщо під час архівації створюються, віддаляються і змінюються файли і каталоги, то інформація в створюваному архіві може виявитися протиріччя В той же час, оскільки створення резервної копії може зайняти декілька годин, для цього може знадобитися відключення системи на велику частину ночі, що не завжди прийнятно. З цієї причини були розроблені алгоритми, здатні швидко фіксувати стан файлової системи для її архівації, копіюючи критичні структури даних. Подальші зміни файлів і каталогів вимагали замість їх заміни додаткового копіювання окремих блоків [160]. Таким чином, файлова система як би заморожується у момент фіксації і може архівуватися пізніше.

Нарешті, по-п'яте, створення резервних копій створює безліч нетехнічних проблем. Краща система безпеки, що охороняє інформацію, може виявитися даремною, якщо системний адміністратор зберігає усі свої магнітні стрічки з резервними копіями в приміщенні, що не охороняється, яке ще і залишає відкритим. Усе, що треба зробити шпигунові, це заскочити на секунду в кімнату, покласти касету в кишеню і неспішно покинути будівлю. Прощай, безпека. Крім того, щоденна архівація принесе мало користі, якщо при пожежі загинуть не лише комп'ютери, але і стрічки з резервними копіями. З цієї причини резервні копії слід зберігати у видаленому місці, внаслідок чого підтримувати безпеку на досить високому рівні стає ще складніша. Детальне обговорення цього і інших адміністративних питань приводиться в [244]. Нижче ми обговоримо тільки технічні аспекти створення резервних копій файлової системи.

Для створення резервної копії диска на стрічці існує дві стратегії: фізична архівація і логічна архівація. Фізична архівація полягає в по-блочному копіюванні на магнітну стрічку усього диска з блоку 0 по останній блок. Ця програма настільки проста, що, можливо, вона навіть може бути повністю відлагоджена, чого не можна сказати про інші корисні програми.

Та все ж про фізичну архівацію слід сказати декілька слів. По-перше, в копіюванні невживаних блоків диска мало користі. Якщо програма архівації зможе дістати доступ до структури даних, що зберігає інформацію про вільні і зайняті блоки диска, вона може уникнути копіювання блоків, що не використовуються. Проте тоді доведеться перед кожним блоком записувати його номер.

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

Головна перевага фізичної архівації полягає в її простоті і високою швидкістю (зазвичай вона може працювати із швидкістю диска). Основними її не-достатками являються нездатність пропускати певні каталоги, виконувати інкрементну архівацію і відновлювати окремі файли. З цих причин в більшості систем застосовується логічна архівація.

Логічна архівація сканує один або декілька вказаних каталогів з усіма їх підкаталогами і копіює на стрічку файли, що все містяться в них, і каталоги, що змінилися з вказаної дати (наприклад, з моменту останньої архівації). Таким чином, при логічній архівації на магнітну стрічку записуються послідовності детально ідентифікованих каталогів і файлів, що дозволяє відновити окремий файл або каталог.

Оскільки логічна архівація застосовується на практиці частіше за фізичну, познайомимося детальніше з алгоритмом архівації на прикладі, показаному на мал. 6.21. Цей алгоритм використовується в більшості систем UNIX. На малюнку показано дерево файлів з каталогами (квадрати) і файлами (гуртки). Затемнені елементи були змінені з моменту останньої архівації і тому слід створити їх резервну копію. Світлі елементи не потребують архівації. Кожний каталог і файл помічені номером свого i-вузла.