Введення в файлові системи unix

У першій статті циклу ми розглядали вміст BIOS'овской і Unix'ов таблиць розділів за допомогою, відповідно, утиліт fdisk і disklabel. У цій статті ми продовжимо розмову і розглянемо використання утиліти newfs, а так же поговоримо про індексних таблицях.

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

Отже, підрахуємо, скільки блоків міститься на циліндрі:

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

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

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

Продовжуючи думати як файлова система, можна прийти до висновку, що має сенс не віддавати цілий блок для одного маленького файлу. Однак, зараз саме час подумати, яким чином ви організуєте вашу таблицю в умовах того, що в одному блоці може бути більше одного файлу. Якщо ви просто почнете набивати в блок стільки файлів, скільки можна розмістити в 512 байтах, то яким чином ви будете відслідковувати, де закінчується один файл і починається інший? Що буде, якщо ви видалите файл розміром 10 байт, а на його місце запишіть файл розміром 8 байт і куди ви запишіть інформацію про решту 2 байтах в разі, якщо ви захочете записати туди два однобайтових файлу? Відразу видно, що подібна схема швидко втрачає працездатність.

Давайте подивимося, що у нас знаходиться на іншій чаші ваг. Що станеться, якщо вам знадобиться записувати файли, розмір яких більше, ніж розмір фізичного або логічного блоку даних? Для збереження на диску такого файлу, вам, зрозуміло, доведеться задіяти більше одного блоку даних. Припустимо, що ви хочете зберегти файл об'ємом 1000 байт. Для цього будуть потрібні два фізичних блоку по 512 байт, і, відповідно, у вашій індексного таблиці будуть два записи. Вам також доведеться подумати над тим, як вносити туди ці записи, оскільки тепер важливий порядок їх внесення. У даній ситуації недостатньо просто знати, що файл знаходиться, скажімо, в блоках 3 і 4. Вам обов'язково треба бути впевненими, що перші 512 байт файлу знаходяться саме в блоці номер три, а решта в четвертому блоці.

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

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

Нас цікавлять тільки деякі ключі. Почнемо з ключа «-b»:

Вказує розмір блоку в файлової системі в байтах. Він повинен бути ступенем числа 2. За замовчуванням розмір 8192 байт. Найменший можливий розмір 4096 байт.

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

Вказує розмір фрагмента файлової системи в байтах. Значення має лежати в межах від размер_блока / 8 до размер_блока і бути ступенем числа 2. Стандартною розмір 1024 байт.

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

Тепер розглянемо ключ "-i»:

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

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

Ось ще два параметри, про які слід тут згадати, оскільки вони впливають на продуктивність операції читання / запису файлової системи FFS. По-перше, ключ -m:

Продуктивність будь-якої файлової системи починає «просідати», коли їй не вистачає вільних блоків для зберігання даних. Справа в тому, що файлові системи «воліють» зберігати файли одного каталогу в суміжних блоках (тобто поруч один з одним), а це стає скрутним, коли кількість вільних блоків зменшується і системі доводиться витрачати час на їх пошук. Творці FFS вказують, що її продуктивність різко падає, коли диск заповнюється на більш ніж 90%. Коли файлова система досягає порогу, встановленого для обсягу вільного місця (за замовчуванням 8%), для звичайних користувачів відбувається блокування записи будь-яких файлів. Користувачі будуть отримувати повідомлення про помилку, і, ймовірно, нагадають адміністратору про ситуації, що склалася. Суперкористувач зберігає можливість запису інформації на диск і використання залишилися вільними блоків, однак в цей момент краще зайнятися розробкою плану порятунку файлової системи, а не чекати, поки на ній скінчиться місце.

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

Більшість файлових систем використовують спеціальні алгоритми для того, щоб визначити, які файли повинні обіймати будь блоки на диску. Цей ключ використовується для визначення, якої стратегії оптимізації повинен дотримуватися алгоритм FFS для розміщення файлів. У ситуації достатку вільного дискового простору можна використовувати оптимізацію по швидкості (time). Однак коли обсяг вільного місця на диску переходить межу, що визначається ключем «-m», оптимізація фрагментації (space) стає більш важливим завданням, ніж швидкість.

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