- файлова система Файлова система - це частина операційної системи, призначення якої полягає в тому,...
- типи файлів
- Логічна організація файлу
- Фізична організація і адреса файлу
- Права доступу до файлу
- кешування диска
- Загальна модель файлової системи
- Відображені в пам'ять файли
- Сучасні архітектури файлових систем
файлова система Наша команда-партнер Artmisto
Файлова система - це частина операційної системи, призначення якої полягає в тому, щоб забезпечити користувачеві зручний інтерфейс при роботі з даними, що зберігаються на диску, і забезпечити спільне використання файлів кількома користувачами і процесами.
У широкому розумінні поняття "файлова система" включає:
- сукупність всіх файлів на диску,
- набори структур даних, використовуваних для управління файлами, такі, наприклад, як каталоги файлів, дескриптори файлів, таблиці розподілу вільного і зайнятого простору на диску,
- комплекс системних програмних засобів, що реалізують управління файлами, зокрема: створення, знищення, читання, запис, іменування, пошук і інші операції над файлами.
імена файлів
Файли ідентифікуються іменами. Його користувачі дати йому файлів символьні імена, при цьому враховуються обмеження ОС як на використовувані символи, так і на довжину імені. До недавнього часу ці межі були досить вузькими. Так у популярній файлової системи FAT довжина імен обмежується певною схемою 8.3 (8 символів - власне ім'я, 3 символу - розширення імені), а в ОС UNIX System V ім'я не може містити більше 14 символів. Однак користувачеві набагато зручніше працювати з довгими іменами, оскільки вони дозволяють дати файлу дійсно мнемонічне назва, по якому навіть через досить великий проміжок часу можна буде згадати, що містить цей файл. Тому сучасні файлові системи, як правило, підтримують довгі символьні імена файлів. Наприклад, Windows NT у своїй новій файлової системи NTFS встановлює, що ім'я файлу може містити до 255 символів, не рахуючи завершального нульового символу.
При переході до довгих іменах виникає проблема сумісності з раніше створеними додатками, що використовують короткі імена. Щоб додаток могли звертатися до файлів відповідно до прийнятих раніше угодами, файлова система повинна вміти надавати еквівалентні короткі імена (псевдоніми) файлів, які мають довгі імена. Таким чином, одним із важливих завдань стає проблема генерації відповідних коротких імен.
Довгі імена підтримуються не тільки новими файловими системами, а й новими версіями добре відомих файлових систем. Наприклад, в ОС Windows 95 використовує файлову систему VFAT, що представляє собою істотно змінений варіант FAT. Серед багатьох інших удосконалень одним з головних достоїнств VFAT є підтримка довгих імен. Крім проблеми генерації еквівалентних коротких імен, при реалізації нового варіанту FAT важливим завданням було завдання зберігання довгих імен за умови, що принципово метод зберігання і структура даних на диску не повинні були змінитися.
Зазвичай різні файли можуть мати однакові символьні імена. У цьому випадку файл однозначно ідентифікується так званим складовим ім'ям, що представляє собою послідовність символьних імен каталогів. У деяких системах одному і тому ж файлу не може бути дано кілька різних імен, а в інших таке обмеження відсутнє. В останньому випадку операційна система привласнює файлу додатково унікальне ім'я, так, щоб можна було встановити взаємно-однозначна відповідність між файлом і його унікальним ім'ям. Унікальне ім'я являє собою числовий ідентифікатор і використовується програмами операційної системи. Прикладом такого унікального імені файлу є номер індексного дескриптора в системі UNIX.
типи файлів
Файли бувають різних типів: звичайні файли, спеціальні файли, файли-каталоги.
Звичайні файли в свою чергу поділяються на текстові та двійкові. Текстові файли складаються з рядків символів, представлених в ASCII-коді. Це можуть бути документи, вихідні тексти програм і т.п. Текстові файли можна прочитати на екрані і роздрукувати на принтері. Двійкові файли не використовують ASCII-коди, вони часто мають складну внутрішню структуру, наприклад, об'єктний код програми або архівний файл. Всі операційні системи повинні вміти розпізнавати хоча б один тип файлів - їх власні виконувані файли.
Спеціальні файли - це файли, асоційовані з пристроями введення-виведення, які дозволяють користувачеві виконувати операції введення-виведення, використовуючи звичайні команди запису в файл або читання з файлу. Ці команди обробляються спочатку програмами файлової системи, а потім на деякому етапі виконання запиту перетворюються ОС в команди управління відповідним пристроєм. Спеціальні файли, так само як і пристрої введення-виведення, діляться на блок-орієнтовані і байт-орієнтовані.
Каталог - це, з одного боку, група файлів, об'єднаних користувачем виходячи з деяких міркувань (наприклад, файли, що містять програми ігор, або файли, складові один програмний пакет), а з іншого боку - це файл, який містить системну інформацію про групу файлів, його складових. У каталозі міститься список файлів, що входять в нього, і встановлюється відповідність між файлами і їх характеристиками (атрибутами).
У різних файлових системах можуть використовуватися в якості атрибутів різні характеристики, наприклад:
- інформація про дозволений доступ,
- пароль для доступу до файлу,
- власник файлу,
- творець файлу,
- ознака "тільки для читання",
- ознака "прихований файл",
- ознака "системний файл",
- ознака "архівний файл",
- ознака "двійковий / символьний",
- ознака "тимчасовий" (видалити після завершення процесу),
- ознака блокування,
- довжина запису,
- покажчик на ключове поле в записі,
- довжина ключа,
- часи створення, останнього доступу і останньої зміни,
- поточний розмір файлу,
- максимальний розмір файлу.
Каталоги можуть безпосередньо містити значення характеристик файлів, як це зроблено в файлової системі MS-DOS, або посилатися на таблиці, що містять ці характеристики, як це реалізовано в ОС UNIX (рисунок 2.31). Каталоги можуть утворювати ієрархічну структуру за рахунок того, що каталог нижчого рівня може входити в каталог більш високого рівня (рисунок 2.32).
Мал. 2.31. Структура каталогів: а - структура записи каталогу MS-DOS (32 байта);
б - структура записи каталогу ОС UNIX
Ієрархія каталогів може бути деревом або мережею. Каталоги утворюють дерево, якщо файлу дозволено входити тільки в один каталог, і мережа - якщо файл може входити відразу в декілька каталогів. У MS-DOS каталоги утворюють деревовидну структуру, а в Unix'е - мережеву. Як і будь-який інший файл, каталог має символьне ім'я і однозначно ідентифікується складовим ім'ям, що містить ланцюжок символьних імен всіх каталогів, через які проходить шлях від кореня до даного каталогу.
Мал. 2.32. Логічна організація файлової системи
а - однорівнева; б - ієрархічна (дерево); в - ієрархічна (мережа)
Логічна організація файлу
Програміст має справу з логічною організацією файлу, представляючи файл у вигляді певним чином організованих логічних записів. Логічна запис - це найменший елемент даних, яким може оперувати програміст при обміні з зовнішнім пристроєм. Навіть якщо фізичний обмін з пристроєм здійснюється великими одиницями, операційна система забезпечує програмісту доступ до окремої логічного запису. На малюнку 2.33 показані кілька схем логічної організації файлу. Записи можуть бути фіксованої довжини або змінної довжини. Записи можуть бути розташовані в файлі послідовно (послідовна організація) або в більш складному порядку, з використанням так званих індексних таблиць, що дозволяють забезпечити швидкий доступ до окремої логічного запису (індексного-послідовна організація). Для ідентифікації запису може бути використано спеціальне поле записи, зване ключем. У файлових системах ОС UNIX і MS-DOS файл має найпростішу логічну структуру - послідовність однобайтових записів.
Мал. 2.33. Способи логічної організації файлів
Фізична організація і адреса файлу
Фізична організація файлу описує правила розташування файлу на пристрої зовнішньої пам'яті, зокрема на диску. Файл складається з фізичних записів - блоків. Блок - найменша одиниця даних, якою зовнішній пристрій обмінюється з оперативною пам'яттю. Безперервне розміщення - найпростіший варіант фізичної організації (рисунок 2.34, а), при якому файлу надається послідовність блоків диска, що утворюють єдиний суцільний ділянку дискової пам'яті. Для завдання адреси файлу в цьому випадку досить вказати тільки номер початкового блоку. Інша перевага цього методу - простота. Але є і два істотні недоліки. По-перше, під час створення файлу заздалегідь не відома його довжина, а значить не відомо, скільки пам'яті треба зарезервувати для цього файлу, по-друге, при такому порядку розміщення неминуче виникає фрагментація, і простір на диску використовується не ефективно, так як окремі ділянки маленького розміру (мінімально 1 блок) можуть залишитися не використовуваними.
Наступний спосіб фізичної організації - розміщення у вигляді пов'язаного списку блоків дискової пам'яті (рисунок 2.34, б). При такому способі на початку кожного блоку міститься покажчик на наступний блок. У цьому випадку адреса файлу також може бути заданий одним числом - номером першого блоку. На відміну від попереднього способу, кожен блок може бути приєднаний в ланцюжок будь-якого файлу, отже фрагментація відсутня. Файл може змінюватися під час свого існування, нарощуючи число блоків. Недоліком є складність реалізації доступу до довільно заданого місця файлу: для того, щоб прочитати п'ятий по порядку блок файлу, необхідно послідовно прочитати чотири перших блоку, простежуючи ланцюжок номерів блоків. Крім того, при цьому способі кількість даних файлу, що містяться в одному блоці, не дорівнює ступеню двійки (одне слово витрачено на номер наступного блоку), а багато програм читають дані блоками, розмір яких дорівнює ступеню двійки.
Мал. 2.34. Фізична організація файлу
а - безперервне розміщення; б - пов'язаний список блоків;
в - зв'язаний список індексів; г - перелік номерів блоків
Популярним способом, використовуваним, наприклад, в файлової системі FAT операційної системи MS-DOS, є використання пов'язаного списку індексів. З кожним блоком зв'язується певний елемент - індекс. Індекси розташовуються в окремій області диска (в MS-DOS це таблиця FAT). Якщо деякий блок розподілений деякому файлу, то індекс цього блоку містить номер наступного блоку даного файлу. При такій фізичній організації зберігаються всі достоїнства попереднього способу, але знімаються обидва зазначених недоліки: по-перше, для доступу до довільного місця файлу досить прочитати тільки блок індексів, відлічити потрібну кількість блоків файлу по ланцюжку і визначити номер потрібного блоку, і, по-друге , дані файлу займають блок цілком, а значить мають об'єм, рівний ступеня двійки.
На закінчення розглянемо завдання фізичного розташування файлу шляхом простого перерахування номерів блоків, займаних цим файлом. ОС UNIX використовує варіант даного способу, що дозволяє забезпечити фіксовану довжину адреси, незалежно від розміру файлу. Для зберігання адреси файлу виділено 13 полів. Якщо розмір файлу менше або дорівнює 10 блокам, то номери цих блоків безпосередньо перераховані в перших десяти полях адреси. Якщо розмір файлу більше 10 блоків, то наступне 11-е поле містить адресу блоку, в якому можуть бути розташовані ще 128 номерів наступних блоків файлу. Якщо файл більше, ніж 10 + 128 блоків, то використовується 12-е поле, в якому знаходиться номер блоку, що містить 128 номерів блоків, які містять по 128 номерів блоків даного файлу. І, нарешті, якщо файл більше 10 + 128 + 128 (128, то використовується останнє 13-е поле для потрійний непрямої адресації, що дозволяє задати адресу файлу, що має розмір максимум 10+ 128 + 128 (128 + 128 (128 (128.
Права доступу до файлу
Визначити права доступу до файлу - значить визначити для кожного користувача набір операцій, які він може застосувати до даного файлу. У різних файлових системах може бути визначений свій список диференційовних операцій доступу. Цей список може включати наступні операції:
- створення файлу,
- знищення файлу,
- відкриття файлу,
- закриття файлу,
- читання файлу,
- запис в файл,
- доповнення файлу,
- пошук у файлі,
- отримання атрибутів файлу,
- встановлення нових значень атрибутів,
- перейменування,
- виконання файлу,
- читання каталогу,
та інші операції з файлами і каталогами.
У найзагальнішому випадку права доступу можуть бути описані матрицею прав доступу, в якій стовпці відповідають всім файлам системи, рядки - всім користувачам, а на перетині рядків і стовпців вказуються дозволені операції (рисунок 2.35). У деяких системах користувачі можуть бути розділені на окремі категорії. Для всіх користувачів однієї категорії визначаються єдині права доступу. Наприклад, в системі UNIX всі користувачі поділяються на три категорії: власника файлу, членів його групи і всіх інших.
Мал. 2.35. Матриця прав доступу
Розрізняють два основні підходи до визначення прав доступу:
- виборчий доступ, коли для кожного файлу і кожного користувача сам власник може визначити допустимі операції;
- мандатний підхід, коли система наділяє користувача певними правами по відношенню до кожного ресурсу, що (в даному випадку файлу) в залежності від того, до якої групи користувач віднесений.
кешування диска
У деяких файлових системах запити до зовнішніх пристроїв, в яких адресація здійснюється блоками (диски, стрічки), перехоплюються проміжним програмним шаром-підсистемою буферизації. Підсистема буферизації є буферний пул, що розташовується в оперативній пам'яті, і комплекс програм, які керують цим пулом. Кожен буфер пулу має розмір, рівний одному блоку. Під час отримання запиту на читання деякого блоку підсистема буферизації переглядає свій буферний пул і, якщо знаходить необхідний блок, то копіює його в буфер запитуючої процесу. Операція введення-виведення вважається виконаним, хоча фізичного обміну з пристроєм не відбувалося. Очевидним є виграш у часі доступу до файлу. Якщо ж потрібний блок в буферному пулі відсутній, то він зчитується з пристрою і одночасно з передачею запитувачу процесу копіюється в один з буферів підсистеми буферизації. При відсутності вільного буфера на диск витісняється найменш використовувана інформація. Таким чином, підсистема буферизації працює за принципом кеш-пам'яті.
Загальна модель файлової системи
Функціонування будь-якої файлової системи можна уявити багаторівневої моделлю (рисунок 2.36), в якій кожен рівень надає деякий інтерфейс (набір функцій) вищому рівневі, а сам, в свою чергу, для виконання своєї роботи використовує інтерфейс (звертається з набором запитів) нижчого рівня.
Мал. 2.36. Загальна модель файлової системи
Завданням символьного рівня є визначення по символьному імені файлу його унікального імені. У файлових системах, в яких кожен файл може мати тільки одне символьне ім'я (наприклад, MS-DOS), цей рівень відсутній, так як символьне ім'я, присвоєне файлу користувачем, є одночасно унікальним і може бути використано операційною системою. В інших файлових системах, в яких один і той же файл може мати кілька символьних імен, на даному рівні проглядається ланцюжок каталогів для визначення унікального імені файлу. У файлової системи UNIX, наприклад, унікальним ім'ям є номер індексного дескриптора файлу (i-node).
На наступному, базовому рівні по унікальному імені файлу визначаються його характеристики: права доступу, адреса, розмір та інші. Як вже було сказано, характеристики файлу можуть входити до складу каталогу або зберігатися в окремих таблицях. При відкритті файлу його характеристики переміщаються з диска в оперативну пам'ять, щоб зменшити середній час доступу до файлу. У деяких файлових системах (наприклад, HPFS) при відкритті файлу разом з його характеристиками в оперативну пам'ять переміщаються кілька перших блоків файлу, що містять дані.
Наступним етапом реалізації запиту до файлу є перевірка прав доступу до нього. Для цього порівнюються повноваження користувача або процесу, які видали запит, зі списком дозволених видів доступу до даного файлу. Якщо запитуваний вид доступу дозволений, то виконання запиту триває, якщо немає, то видається повідомлення про порушення прав доступу.
На логічному Рівні визначаються координати запитуваної логічної запису у файлі, тобто нужно візначіті, на Якій відстані (в байтах) від качана файлу находится необхідна логічна запис. При цьом абстрагуються від фізічного Розташування файлу, ВІН представляється у виде безперервної послідовності байт. Алгоритм роботи даного уровня Залежить від логічної организации файлу. Наприклад, якщо файл організований як послідовність логічних записів фіксованої довжини l, то n-ая логічна запис має зсув l ((n-1) байт. Для визначення координат логічного запису у файлі з індексного-послідовною організацією виконується читання таблиці індексів (ключів), в якій безпосередньо вказується адреса логічного запису.
Мал. 2.37. Функції фізичного рівня файлової системи
Вихідні дані:
V - розмір блоку
N - номер першого блоку файлу
S - зміщення логічного запису у файлі
Потрібно визначити на фізичному рівні:
n - номер блоку, що містить необхідну логічну запис
s - зсув логічного запису в межах блоку
n = N + [S / V], де [S / V] - ціла частина числа S / V
s = R [S / V] - дрібна частина числа S / V
На фізичному рівні файлова система визначає номер фізичної блоку, який містить необхідну логічну запис, і зсув логічного запису у фізичному блоці. Для вирішення цього завдання використовуються результати роботи логічного рівня - зміщення логічного запису у файлі, адреса файлу на зовнішньому пристрої, а також відомості про фізичну організації файлу, включаючи розмір блоку. Малюнок 2.37 ілюструє роботу фізичного рівня для найпростішої фізичної організації файлу у вигляді безперервної послідовності блоків. Підкреслимо, що завдання фізичного рівня вирішується незалежно від того, як був логічно організований файл.
Після визначення номера фізичної блоку, файлова система звертається до системи введення-виведення для виконання операції обміну з зовнішнім пристроєм. У відповідь на цей запит в буфер файлової системи буде переданий потрібний блок, в якому на підставі отриманого при роботі фізичного рівня зсуву вибирається необхідна логічна запис.
Відображені в пам'ять файли
У порівнянні з доступом до пам'яті, традиційний доступ до файлів виглядає заплутаним і незручним. З цієї причини деякі ОС, починаючи з MULTICS, забезпечують відображення файлів в адресний простір виконуваного процесу. Це виражається в появі двох нових системних викликів: MAP (відобразити) і UNMAP (скасувати відображення). Перший виклик передає операційній системі в якості параметрів ім'я файлу і віртуальний адреса, і операційна система відображає вказаний файл у віртуальний адресний простір за вказаною адресою.
Припустимо, наприклад, що файл f має довжину 64 К і відображається на область віртуального адресного простору з початковим адресою 512 К. Після цього будь-яка машинна команда, яка читає вміст байта за адресою 512 К, отримує 0-ій байт цього файлу і т.д . Очевидно, що запис за адресою 512 К + 1100 змінює 1100 байт файлу. При завершенні процесу на диску залишається модифікована версія файлу, як якщо б він був змінений комбінацією викликів SEEK і WRITE.
Насправді при відображенні файлу внутрішні системні таблиці змінюються так, щоб даний файл служив сховищем сторінок віртуальної пам'яті на диску. Таким чином, читання за адресою 512 К викликає сторінковий відмову, в результаті чого сторінка 0 переноситься в фізичну пам'ять. Аналогічно, запис за адресою 512 К + 1 100 викликає сторінковий відмову, в результаті якого сторінка, що містить цю адресу, переміщається в пам'ять, після чого здійснюється запис в пам'ять по необхідному адресою. Якщо ця сторінка витісняється з пам'яті алгоритмом заміни сторінок, то вона записується назад в файл у відповідне його місце. При завершенні процесу все відображені і модифіковані сторінки переписуються з пам'яті в файл.
Відображення файлів найкраще працює в системі, яка підтримує сегментацію. У такій системі кожен файл може бути відображений в свій власний сегмент, так що k-ий байтв файлі є k-им байтом сегмента. На малюнку 2.38, а зображено процес, який має два сегменти-коду і даних. Припустимо, що цей процес копіює файли. Для цього він спочатку відображає файл-джерело, наприклад, abc. Потім він створює порожній сегмент і відображає на нього файл призначення, наприклад, файл ddd.
З цього моменту процес може копіювати сегмент-джерело в сегмент-приймач за допомогою звичайного програмного циклу, що використовує команди пересилання в пам'яті типу mov. Ніякі виклики READ або WRITE не потрібні. Після виконання копіювання процес може здійснити телефонний дзвінок UNMAP для видалення файлу з адресного простору, а потім завершитися. Вихідний файл ddd буде існувати на диску, як якщо б він був створений звичайним способом.
Хоча відображення файлів виключає потребу у виконанні вводу-виводу і тим самим полегшує програмування, цей спосіб породжує і деякі нові проблеми. По-перше, для системи складно дізнатися точну довжину вихідного файлу, в даному прикладі ddd. Простіше вказати найбільший номер записаної сторінки, але немає способу дізнатися, скільки байт в цій сторінці було записано. Припустимо, що програма використовує тільки сторінку номер 0, і після виконання все байти все ще встановлені в значення 0 (їх початкове значення). Бути може, файл складається з 10 нулів. А може бути, він складається з 100 нулів. Як це візначіті? Операційна система не може це повідомити. Все, що вона може зробити, так це створити файл, довжина якого дорівнює розміру сторінки.
Мал. 2.38. (а) Сегменти процесу перед відображенням файлів в адресний простір; (б) Процес
після відображення існуючого файлу abc в один сегмент і створення нового сегмента для файлу ddd
Друга проблема проявляється (потенційно), якщо один процес відображає файл, а інший процес відкриває його для звичайного файлового доступу. Якщо перший процес змінює сторінку, то ця зміна не буде відображено у файлі на диску доти, поки сторінка не буде витіснена на диск. Підтримка узгодженості даних файлу для цих двох процесів вимагає від системи великих турбот.
Третя проблема полягає в тому, що файл може бути більше, ніж сегмент, і навіть більше, ніж всі віртуальний адресний простір. Єдиний спосіб її вирішення полягає в реалізації виклику MAP таким чином, щоб він міг відображати не весь файл, а його частина. Хоча така робота, очевидно, менш зручна, ніж відображення цілого файлу.
Сучасні архітектури файлових систем
Розробники нових операційних систем прагнуть забезпечити користувача можливістю працювати відразу з декількома файловими системами. У новому розумінні файлова система складається з багатьох складових, в число яких входять і файлові системи в традиційному розумінні.
Нова файлова система має багаторівневу структуру (рисунок 2.39), на верхньому рівні якої розташовується так званий перемикач файлових систем (в Windows 95, наприклад, такий перемикач називається встановлюються диспетчером файлової системи - installable filesystem manager, IFS). Він забезпечує інтерфейс між запитами програми та конкретної файлової системою, до якої звертається цей додаток. Перемикач файлових систем перетворює запити в формат, що сприймається наступним рівнем - рівнем файлових систем.
Мал. 2.39. Архітектура сучасної файлової системи
Кожен компонент рівня файлових систем виконаний у вигляді драйвера відповідної файлової системи і підтримує певну організацію файлової системи. Перемикач є єдиним модулем, який може звертатися до драйверу файлової системи. Додаток не може звертатися до нього безпосередньо. Драйвер файлової системи може бути написаний у вигляді реєнтерабельним коду, що дозволяє відразу декільком додаткам виконувати операції з файлами. Кожен драйвер файлової системи в процесі власної ініціалізації реєструється у перемикача, передаючи йому таблицю точок входу, які будуть використовуватися при наступних зверненнях до файлової системи.
Для виконання своїх функцій драйвери файлових систем звертаються до підсистеми введення-виведення, що утворює наступний шар файлової системи нової архітектури. Підсистема введення виведення - це складова частина файлової системи, яка відповідає за завантаження, ініціалізацію і управління всіма модулями нижчих рівнів файлової системи. Зазвичай ці модулі є драйвери портів, які безпосередньо займаються роботою з апаратними засобами. Крім цього підсистема вводу-виводу забезпечує деякий сервіс драйверам файлової системи, що дозволяє їм здійснювати запити до конкретних пристроїв. Підсистема введення-виведення має постійно бути присутньою в пам'яті і організовувати спільну роботу ієрархії драйверів пристроїв. У цю ієрархію можуть входити драйвери пристроїв певного типу (драйвери жорстких дисків або накопичувачів на стрічках), драйвери, підтримувані постачальниками (такі драйвери перехоплюють запити до блокових пристроїв і можуть частково змінити поведінку існуючого драйвера цього пристрою, наприклад, зашифрувати дані), драйвери портів, які керують конкретними адаптерами.
Велике число рівнів архітектури файлової системи забезпечує авторам драйверів пристроїв велику гнучкість - драйвер може отримати управління на будь-якому етапі виконання запиту - від виклику додатком функції, яка займається роботою з файлами, до того моменту, коли працює на найнижчому рівні драйвер пристрою починає переглядати регістри контролера . Багаторівневий механізм роботи файлової системи реалізований за допомогою ланцюжків виклику.
В ході ініціалізації драйвер пристрою може додати себе до ланцюжку виклику деякого пристрою, визначивши при цьому рівень подальшого звернення. Підсистема введення-виведення поміщає адресу цільової функції в ланцюжок виклику пристрою, використовуючи заданий рівень для того, щоб належним чином впорядкувати ланцюжок. У міру виконання запиту, підсистема вводу-виводу послідовно викликає всі функції, раніше поміщені в ланцюжок виклику.
Внесена в ланцюжок виклику процедура драйвера може вирішити передати запит далі - в зміненому або в незміненому вигляді - на наступний рівень, або, якщо це можливо, процедура може задовольнити запит, не передаючи його далі по ланцюжку.
попередня глава || Зміст || наступна глава
Як це візначіті?б - структура записи каталогу ОС UNIX
а - однорівнева; б - ієрархічна (дерево); в - ієрархічна (мережа)
а - безперервне розміщення; б - пов'язаний список блоків;
в - зв'язаний список індексів; г - перелік номерів блоків
V - розмір блоку
N - номер першого блоку файлу
S - зміщення логічного запису у файлі
s = R [S / V] - дрібна частина числа S / V
після відображення існуючого файлу abc в один сегмент і створення нового сегмента для файлу ddd
