5.3.2. Реалізація файлів

Ймовірно, найбільш важливим моментом в реалізації механізму зберігання

файлів є врахування відповідності блоків диска файлів. Для визначення того,

який блок якому файлу належить, в різних операційних системах

застосовуються різні методи. Деякі з них розглянуті в даному розділі.

Нерозривні файли

Найпростішою схемою виділення файлів певних блоків на диску є система, в якій файли являють собою набори суміжних блоків диска.

Тоді на диску з блоками по 1 Кбайт файл розміром в 50 Кбайт займатиме

50 послідовних блоків. У нерозривних файлів є два істотних

переваги. По-перше, таку модель легко реалізувати, так як системі, щоб

визначити, які блоки належать тому чи іншому файлу, потрібно стежити за все

лише за двома числами: номером першого блоку файлу і числом блоків у файлі.

Знаючи перший блок файлу, будь-який інший його блок легко отримати за допомогою

простої операції додавання.

По-друге, при роботі з нерозривними файлами продуктивність просто

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

Потрібен тільки одна операція позиціонування (для першого блоку). Після

цього більше не потрібно шукати циліндри і витрачати час на очікування повороту

диска, тому дані можуть зчитуватися з максимальною швидкістю, на яку

здатний диск. Таким чином, безперервні файли легко реалізуються і для

них характерна висока продуктивність.

На жаль, нерозривні файли мають і серйозний недолік: їх

використання веде до фрагментації дисків. Спочатку фрагментація не є

проблемою, оскільки кожен новий файл можна записати відразу слідом за

попереднім. Однак у кінцевому рахунку диск заповниться, і виникне необхідність

стиснути його (що недозволено дорого) або реорганізувати вільні

фрагменти. Останнє вимагає ведення списку вільних фрагментів, що цілком

реально. До того ж, при створенні нового файлу необхідно знати його кінцевий

розмір, щоб розмістити в блоці відповідного розміру.

Як було зазначено в розділі 1, у міру появи нових поколінь технологій

в обчислювальній техніці історія може повторюватися. Багато років тому виділення пам'яті безперервними блоками завдяки простоті і високої

продуктивності застосовувалося в файлових системах магнітних стрічок (у той час

зручності користувача не надавалося великого значення). Потім від нього

відмовилися, визнавши неприпустимою необхідність вказувати розмір файлу в момент

його створення. Однак з винаходом CD-ROM, DVD та інших видів

оптичних носіїв з однократним записом нерозривні файли знову опинилися

в фаворі. Подібні носії допускають виділення пам'яті безперервними

блоками, більш того, воно широко поширене. Розміри всіх файлів відомі

заздалегідь і незмінні протягом усього терміну використання файлової

системи CD-ROM. Висновок: важливо вивчати старі системи і вдалі концептуально

прості ідеї, оскільки в майбутньому вони можуть отримати абсолютно несподіваною

несподіване застосування.

Пов'язані списки

Другий метод розміщення файлів полягає в представленні кожного файлу в

вигляді пов'язаного списку блоків диска (рис. 5.7). Перше слово кожного блоку є-

є покажчиком на наступний блок. В іншій частині блоку зберігаються дані.

Рис. 5.7. Розміщення файлу в вигляді пов'язаного списку блоків диска

На відміну від систем з нерозривними файлами, пов'язаний список дозволяє ис-

використовувати кожен блок диска. Ні втрат дискового простору на фрагменти

фрагментацію (якщо не рахувати втрати в останніх блоках файлу). Крім того, в каталозі

потрібно зберігати тільки адресу першого блоку файлу. Всю іншу інформацію

можна знайти за вказаною адресою.

У той же час, хоча послідовний доступ до такого файлу нескладний, вироб-

довільний доступ виявляється дуже повільним. Щоб отримати доступ до бло-

блоку п, операційна система повинна спочатку прочитати перші п - 1 блоків по

черзі. Очевидно, така схема виявляється повільною.

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

двійки, оскільки декілька байтів відведено під покажчик. Хоча це й не критично,

нестандартний розмір знижує ефективність, оскільки багато програм

зчитують і записують блоки розміром, що становить ступінь двійки. Так

як покажчик на наступний блок розташований на початку поточного блоку, читання

блоку повноцінного розміру вимагає отримання та конкатенації двох блоків. Це

призводить до додаткових накладних витрат на копіювання.

Пов'язані списки з індексацією

Обидва нестачі попередньої схеми організації файлів у вигляді списків можуть

бути усунені, якщо покажчики на наступні блоки зберігати не прямо в бло-

блоках, а в окремій таблиці, що завантажується в пам'ять. На рис. 5.8 показаний зовн-

зовнішній вигляд такої таблиці для файлів з рис. 5.7. На обох малюнках присутні

два файли. Файл А займає блоки диска 4, 7, 2, 10 і 12, а файл В - блоки 6, 3,

І і 14. За допомогою таблиці ми можемо почати з блоку 4 і слідувати по ланцюжку

до кінця файлу. Ті самі дії застосовні для другого файлу, якщо почати з бло-

блоку 6. Обидві ланцюжка завершуються спеціальним маркером, що не є допусти-

припустимим номером блоку (наприклад, -1). Така таблиця, завантажувана в оперативну

пам'ять, називається таблицею розміщення файлів (File Allocation Table, FAT).

Рис. 5.8. Таблиця розміщення файлів

При такій організації все блоки доступні для даних. Крім того, значною

значно спрощується довільний доступ. Хоча для звернення до будь-якого блоку

файлу все одно знадобиться пройти по ланцюжку всіх посилань аж до

потрібного блоку, в даному випадку вся ланцюжок посилань вже зберігається в пам'яті і

її проходження не вимагає додаткових дискових операцій. Як і в попередньому

попередньому випадку, для доступу до всіх частин файлу в каталозі досить зберігати

один цілий індекс (номер початкового блоку файлу).

Основний недолік цього методу полягає в тому, що вся таблиця повинна по-

постійно перебувати в пам'яті. Для 20-гігабайтного диска з блоками розміром

1 Кбайт потрібна була б таблиця з 20000000 записів, по одній для кожного

з 20000000 блоків диска. Кожен запис має складатися як мінімум з

3 байт. Для прискорення пошуку розмір записів повинен бути збільшений до 4 байт.

Таким чином, резидентна таблиця буде займати 60 або 80 Мбайт опера-

оперативної пам'яті. Таблиця, звичайно, може бути розміщена у віртуальній пам'яті,

але і в цьому випадку вона продовжить займати великий обсяг віртуальної па-

пам'яті і дискового простору, а крім того, призведе до генерації сторінкового

трафіку. Операційні системи MS-DOS і Windows 98 використовують тільки

файлові системи FAT, більше пізні версії Windows також надають

їх підтримку.

Індексні вузли

Останній метод співвіднесення блоків диска файлів полягає в зв'язуванні

з кожним файлом структури даних, званої індексним вузлом (index node),

або i-вузлом (i-node), яка містить атрибути файлу і адреси блоків файлу.

Простий приклад індексного вузла показаний на рис. 5.9. При наявності індексного вузла

можна знайти всі блоки файлу. Велика перевага такої схеми перед

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

кожен індексний вузол займає п байт, а одночасно відкрити можна k

файлів, для масиву індексних вузлів в пам'яті буде потрібно всього kn байт.

Зазвичай ця величина значно менше, ніж розмір таблиці FAT. Це легко

пояснюється. Розмір таблиці, що зберігає список всіх блоків диска, пропорційно

пропорційний ємності самого диска. Для диска з п блоків потрібно п записів в

таблиці. Таким чином, розмір таблиці лінійно зростає з ростом розміру диска.

Для схеми індексних вузлів, навпаки, потрібно масив в пам'яті з

розміром, пропорційним максимальній кількості файлів, які можна

відкрити одночасно. При цьому не важливо, який саме розмір диска, 1, 10

або 100 Гбайт.

З такою схемою пов'язана проблема, суть якої в тому, що при виділенні

кожному файлу фіксованої кількості дискових адрес цієї кількості може

не вистачити. Одне з рішень полягає в резервуванні останнього

дискового адреси не для блоку даних, а для адреси непрямого блоку, що містить

адреси блоків диска. Цей принцип можна розширити і ввести блоки з подвійним

і потрійним рівнем побічно .

Перш ніж прочитати файл, його слід відкрити. При відкритті файлу

операційна система оперує зазначеним користувачем шляхом, щоб знайти

запис в каталозі. Зрозуміло, щоб знайти запис в каталозі, спочатку потрібно

знайти кореневий каталог. Кореневий каталог може мати фіксоване

місце розташування відносно початку розділу або визначатися на основі іншої

інформації. Наприклад, у класичній файлової системи UNIX суперблок

містить відомості про розміри структур даних файлової системи, що передують

області даних. За допомогою суперблоку можна визначити місце розташування

індексних вузлів. Перший індексний вузол вказує на кореневий каталог,

створюваний одночасно з файловою системою UNIX. У Windows XP інформація

завантажувального сектора (який, насправді, займає значно більше,

ніж один сектор) задає розташування головної таблиці файлів (Master File Table,

MFT), за допомогою якої визначається місце розташування інших об'єктів

файлової системи.

Після виявлення кореневого каталогу виконується пошук потрібного запису в

дереві каталогів. Запис каталогу надає інформацію, за допомогою

якої можна знайти дискові блоки. В залежності від системи це може бути

дисковий адресу всього файлу (для нерозривних файлів), номер першого блоку

файлу (обидві схеми з пов'язаними списками) або номер індексного вузла. У всіх

випадках основна функція системи каталогів полягає в перетворенні ASCII-

імені в інформацію, необхідну для пошуку даних.

З цією проблемою тісно пов'язане питання зберігання атрибутів файлу. Кожна

файлова система підтримує різні атрибути файлу, такі як дату

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

Один з очевидних варіантів - розмістити ці відомості безпосередньо в

запис каталогу. У простому випадку каталог являє собою список записів

фіксованого розміру, по одному запису на файл, що містять ім'я файлу

фіксованої довжини, структуру атрибутів і один або кілька дискових

адрес (не більше певного максимуму), що визначають розташування блоків.

Системи з індексними вузлами можуть зберігати атрибути в індексних вузлах, а не

в записах каталогу. У цьому випадку запис каталогу коротше: він містить тільки ім'я файлу і номер індексного вузла.

Загальні файли

У розділі 1 ми коротко згадали про зв'язки між файлами, наприклад, одного проекту,

спрощують спільну роботу з ними декількох користувачів. На рис. 5.10

показана файлова система, однак тепер один з файлів користувача З присутня також в одному з каталогів користувача В.

Рис. 5.10. Файлова система, що містить загальний файл

В UNIX атрибути файлів зберігаються в індексних вузлах, що спрощує спільне використання файлів: будь-яка кількість записів каталогів може вказувати на

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

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

організувати зв'язок з файлом, розташованим на іншому комп'ютері. В UNIX цей

вид зв'язку називається символьної зв'язком, в Windows - ярликом, а в Mac OS

фірми Apple - псевдонімом. Символьні зв'язку можуть застосовуватися в системах, де

атрибути зберігаються в записах каталогів. Нескладно зрозуміти, що синхронізація

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

Каталоги в Windows 98

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

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

структурі Windows 95, яка, на щастя (чи, імовірніше, свідомо, з планами удосконалення в майбутньому), не використовувалася. Найбільш важливим оновленням є поле, що збільшує число бітів для вказівки на початковий блок з 16 до 32. В результаті максимальний розмір файлової системи збільшено з 216 до 232 блоків.

Ця структура розрахована тільки на старі імена файлів у форматі 8 3, успадкованому від MS-DOS і СР / М. А що ж робити з довгими іменами? Щоб забезпечити можливість використання більш довгих імен файлів, одночасно зберігши сумісність з більш ранніми системами, було вирішено ввести додаткові записи каталогів. Для файлів з довгими іменами автоматично генерується скорочена форма імені і поміщається в поля базового імені та розширення базової записи каталогу. Перед базовим записом розміщується стільки записів, скільки потрібно для зберігання довгого імені файлу. Записи

розташовуються у зворотному порядку. Поле атрибутів всіх записів довгого імені

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

Каталоги в UNIX

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

Коли відкривається файл, файлова система повинна знайти на диску вказане їй

ім'я файлу. Розглянемо, як буде відбуватися пошук файлу / usr / ast / mbox.

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

каталозі, щоб визначити номер індексного вузла для файлу / usr /. Виявити індексний вузол за його номером нескладно, так як розташування вузлів фіксовано. Далі система продовжує пошук з цього індексного вузла і знаходить наступний компонент, ast. Виявивши його, система отримує номер індексного вузла для каталогу / usr / ast. Нарешті, в цьому каталозі шукається сам файл mbox. Потім індексний вузол файлу зчитується в пам'ять і залишається там до тих пір, поки файл не буде закрито..

Відносні шляхи обробляються точно так само, як абсолютні, за винятком того, що пошук починається не з кореневого каталогу, а з поточного. У кожному каталозі є записи з іменами точка (.) і дві точки (..), що додаються при створення каталогу. Запис точка (.) відповідає за індексний вузол самого каталогу, а записи дві точки (..) - індексний вузол каталогу верхнього рівня. Таким чином, якщо дано ім'я файлу. . / Dick / prog. с, система знайде дві точки (..) в поточному каталозі, отримає індексний вузол батьківського каталогу і буде шукати в ньому ім'я dick. Для обробки таких імен не застосовується

ніяких спеціальних алгоритмів. З точки зору системи каталогів, це звичайні

ASCII-строки, нічим не відрізняються від інших імен.

Каталоги в NTFS

Поточною файловою системою для продуктів Microsoft на сьогоднішній день є NTFS (New Technology File System - файлова система нової технології). Ця книга не передбачає її детального опису, проте деякі проблеми, з якими стикається NTFS, і їх рішеннями ми ознайомимося. Одна з проблем - довгі імена файлів і шляхів. NTFS підтримує довгі імена файлів (до 255 символів) і шляхів (до 32 767 символів). Оскільки попередні версії Windows в будь-якому випадку не здатні читати файлову систему NTFS, складна структура каталогів із зворотного сумісністю не потрібна, і поле імені має змінну довжину. Також надається підтримка другого імені в форматі 8 3, що дозволяє застарілим системам отримувати доступ до NTFS-файлів по мережі. NTFS передбачає використання в іменах файлів різних алфавітів за допомогою кодування Unicode. В Unicode кожен символ займає 16 біт; цього достатньо для подання безлічі мов з дуже великими

алфавітами (наприклад, японської мови). Однак крім подання алфавітів, властиві й інші проблеми. Навіть серед мов, що використовують латиницю, є свої тонкощі. Так, в деяких мовах (наприклад, в іспанських) певні комбінації двох символів при сортуванні вважаються одним символом. Слова, що починаються з префіксів «ch» і «11», повинні слідувати після слів, що починаються відповідно з префіксів «cz» і «lz». Ще складніше

проблема чутливості до регістру. Якщо за умовчанням імена файлів чутливі до регістру, іноді може виникати необхідність в організації нечутливого до регістру пошуку. Для мов на основі латиниці рішення проблеми очевидно, принаймні, їх носіям. Якщо підтримується тільки одна мова, правила очевидні, однак Unicode дозволяє змішувати різні мови. У багатонаціональній організації один і той же каталог може містити імена файлів на грецькому, російською та японською мовами. Як вирішення проблеми в NTFS введений атрибут файлу, який визначає угоди про регістрі для мови, якою написано його ім'я файлу. За допомогою додаткових атрибутів в NTFS вирішено багато завдань. Якщо в UNIX файл являє собою послідовність байтів, то в NTFS – колекцію атрибутів, де кожен атрибут є потоком байтів. Базова структура даних NTFS - головна таблиця файлів (Master File Table, MFT). Вона підтримує 16 атрибутів, кожен з яких може мати довжину до 1 Кбайт. Якщо цього недостатньо, атрибут можна використовувати як заголовок, що вказує

на додатковий файл з розширеними значеннями атрибута. Такий атрибут називається нерезидентом. Сама таблиця MFT являє собою файл і містить запис для кожного файлу та каталогу файлової системи. Оскільки її обсяг може значно зрости, при створенні NTFS близько 12,5% простору розділу резервується під MFT. Завдяки резервуванню MFT не

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

Як же в NTFS йде справа з даними? Дані просто представляють собою один з атрибутів файлу. Насправді, NTFS-файл може містити кілька потоків даних. Спочатку ця можливість дозволяла Windows-серверів обслуговувати файли клієнтів Apple Macintosh. У вихідній операційної системі Macintosh (до Mac OS 9) всі файли мали два потоки даних. Ці потоки називалися «гілка ресурсів» і «гілка даних». Множинні потоки даних

мають і інші застосування; наприклад, для великого графічного файлу можна

зберігати його зменшений ескіз. Максимальний обсяг потоку складає 264

байта. У той же час система NTFS здатна зберігати вміст невеликих файлів

(До декількох сотень байтів) в заголовку атрибута. Такі файли називаються

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