Мал. 6.13. Простий каталог, що містить записи фіксованої довжини з атрибутами і дисковими адресами (а); каталог, в якому кожен запис являється просто посиланням на I-вузол (б)

Системи, що використовують i-вузли, можуть зберігати атрибути в і-вузлах, а не в записах каталогу. В цьому випадку запис в каталозі може бути коротше: просто ім'я файлу і номер і-вузла. Цей підхід показаний на мал. 6.13, б. Як ми побачимо пізніше, у цього методу є певні переваги в порівнянні з поміщенням атрибутів прямо в каталоговий запис. Два підходи, показані на мал. 6.13, відповідають системам MS - DOS і UNIX, про що ще буде розказано в цій главі.

Досі ми припускали, що файли мають короткі імена фіксованої довжини. У системі MS - DOS файл може мати ім'я завдовжки від 1 до 8 символів, а також розширення завдовжки до 3 символів. У системі UNIX Version 7 імен файлів можуть бути від одного до 14 символів, включаючи розширення. Проте майже усіма сучасними операційними системами підтримуються довші імена файлів змінної довжини. Як це може бути реалізовано?

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

Один з альтернативних підходів полягає у відмові від припущення про те, що усі записи в каталозі повинні мати один і той же розмір. При такому підході кожен запис в каталозі починається з порції фіксованого розміру, запису, що зазвичай починається з довжини, за яким йдуть дані у фіксованому форматі - ідентифікатор власника, дата створення, інформація про захист і інші атрибути. Слідом за заголовком фіксованої довжини йде частина запису перемінної довжини, що містить ім'я файлу (мал. 6.14, а). На малюнку показано три описувачі файлу, project - budget, personnel і fоо. Ім'я кожного файлу завершується спеціальним символом (зазвичай 0), позначеним на малюнку перекресленими квадратиками. Щоб кожен запис в каталозі міг починатися з межі слова, ім'я кожного файлу доповнюється до цілого числа слів байтами, показаними на малюнку затіненими прямокутниками.

Мал. 6.14. Два варіанти реалізації довгих імен : прямо в записі каталогу (а); у "купі" (б)

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

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

У всіх розглянутих нами досі схемах при пошуку файлу каталоги переглядаються лінійно зверху вниз. Для дуже великих каталогів, що містять багато тисяч файлів, такий пошук може зайняти досить багато часу. Один із способів прискорити пошук файлу полягає у використанні хеш-таблиці в кожному каталозі. Нехай розмір такої таблиці дорівнюватиме n. При додаванні в каталог нового файлу його ім'я повинне хешуватись в число від 0 до n-1. Як хеш-функції можуть використовуватися, наприклад, узяття залишку від ділення імені файлу на n. Як альтернатива можна ділити не саме ім'я, а суму слів, що його утворюють. Можливі і інші варіанти.

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

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

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

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

Спільно використовувані файли

Коли декілька користувачів одночасно працюють над одним проектом, їм часто буває треба спільно використовувати одні і ті ж файли. Тому часто виявляється зручним, щоб спільно використовуваний файл одночасно були присутні в різних каталогах, що належать різним користувачам. На мал. 6.15 знову показана файлова система з мал. 6.6, тільки тепер один з файлів користувача З є присутній також в каталозі користувача В. З’єднання між каталогом користувача В і спільно використовуваним файлом називається зв'язком. Сама файлова система тепер є орієнтований ациклічний граф (DAG, Directed Acyclic Graph), а не дерево.