Мал. 6.23. Стани файлової системи : несуперечливе (а); зниклий блок (б); дублікат блоку в списку вільних блоків (в); дублікат блоку даних (г)

Інша можлива ситуація показана на мал. 6.23, ст. Тут ми бачимо блок номер 4, що двічі з'являється у вільному списку. (Дублікати вільних блоків можливі тільки у тому випадку, якщо файлова система дійсно застосовує списки вільних блоків; при використанні бітового масиву така ситуація неможлива.) Вирішення цієї проблеми також нескладно: побудувати список вільних блоків наново.

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

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

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

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

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

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

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

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

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

rm *.0

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

rm * .0

((зверніть увагу на пропуск після зірочки), програма rm видалить усі файли в поточному каталозі, після чого повідомить, що не може знайти файл .о. В системі MS - DOS і деяких інших системах при видаленні файлу встановлюється всього лише один біт в каталозі або в i-вузлі, відмічаючи, що файл видалений. Блоки диска не повертаються в список вільних блоків до тих пір, поки вони не знадобляться. Таким чином, якщо користувач швидко виявить помилку, він зможе відновити видалені файли. У системі Windows видалені файли зазвичай переміщуються в сміттєвий кошик, звідки їх можна при необхідності витягнути. При цьому вільний простір на диску не збільшується до тих пір, поки кошик не буде очищений.

Продуктивність файлової системи

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

Кешування

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

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

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