Нові можливості операційних систем

Зміст

Ефективне використання легковагих процесів в симетричних мультипроцесора

Контекст процесу

Ядерні нитки

Користувальницькі легковагі процеси

Користувальницькі нитки

Методологія застосування легковагих процесів

Сучасні файлові системи

Обмеження традиційних файлових систем

Поширені файлові системи

Файлові системи з журналізацію Ефективне використання легковагих процесів в симетричних мультипроцесора

Підтримувані в сучасних операційних системах (зокрема, в ОС UNIX) поняття нитки (thread), потоку управління, або легковагої процесу на самому справі з'явилися і реалізацію близько 30 років тому. Найбільш відомою операційною системою, орієнтованої на підтримку множинних процесів, які працюють у загальному адресному просторі і з загальними іншими ресурсами, була легендарна ОС Multics. Ця операційна система заслуговує тривалого окремого обговорення, але, природно не в даному курсі. Ми розглянемо (у загальних рисах) особливості легковагих процесів у сучасних варіанти операційної системи UNIX. Як видно, всі або майже весь вміст цього розділу можна легко віднести до будь-якій операційній системі, підтримуючої легковагі процеси. Незважаючи на відмінності в термінології, в різних реалізаціях легковагих процесів виділяються три класи. Але перш, ніж перейти до розгляду цих класів, обговоримо загальну природу процесу в ОС UNIX. Контекст процесу

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

Статична частина контексту процесу системного рівня включає наступне:

A. Описувач процесу, тобто елемент таблиці описувачів існуючих в системі процесів. Описувач процесу включає, зокрема, наступну інформацію:  стан процесу;  фізичну адресу в основний чи зовнішньої пам'яті u-області процесу;        ідентифікатори користувача, від імені якого запущений процес;  ідентифікатор процесу;  іншу інформацію, пов'язану з управлінням процесом.

B. U-область (u-area), індивідуальна для кожного процесу область простору ядра, що володіє тим властивістю, що хоча u-область кожного процесу розташовується в окремому місці фізичної пам'яті, u-області всіх процесів мають один і той же віртуальний адреса в адресному просторі ядра. Саме це означає, що яка б програма ядра не виконувалася, вона завжди виконується як ядерна частина деякого користувацького процесу, і саме того процесу, u-область якого є "видимої" для ядра в даний момент часу. U-область процесу містить:  покажчик на описувач процесу;  ідентифікатори користувача;  лічильник часу, який процес реально виконувався (тобто займав      процесор) в режимі користувача і режимі ядра;  параметри системного виклику;  результати системного виклику;  таблиця дескрипторів відкритих файлів;  граничні розміри адресного простору процесу;  граничні розміри файлу, в який процес може писати;  і т.д.

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

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

Мабуть, наступним за важливістю класом легковагих процесів є для користувача LWP (LightWeight Processes). Механізми цього роду дозволяють користувачам організувати кілька потоків управління в одному адресному просторі. Всі LWP одного користувача процесу спільно використовують всі ресурси процесу. При надходженні процесу сигналу на цей сигнал реагують всі LWP у відповідності зі своїми власними установками. З іншого боку, кожен LWP володіє своїм власним контекстом, що включає, як і у випадку ядерних ниток, стек і реєстрового оточення (зокрема, вміст індивідуального лічильника команд). Будь-якому LWP користувацького процесу відповідає окрема ядерна нитку. Це означає, що кожен LWP може окремо плануватися (і тому LWP одного користувача процесу можуть виконуватися паралельно на різних процесорах симетричного мультипроцесорного комп'ютера), і системні виклики і переривання LWP можуть оброблятися незалежно. Основною перевагою використання LWP є можливість досягнення реального розпаралелювання програми при її виконанні на симетричному мультипроцесорі (на недоліки ми зупинимося нижче). Користувальницькі нитки

Нарешті, до третього класу легковагих процесів відносяться користувальницькі нитки. Вони називаються призначеними для користувача, оскільки реалізуються не ядром ОС, а з допомогою спеціальної бібліотеки функцій (тому, наприклад, в ОС Mach їх називають C-Threads). Це теж дуже стара ідея, до використання якої неодноразово вдавалися всі досвідчені програмісти (тут вже навіть не важливо, в середовищі якої операційної системи виконується програма). Суть ідеї полягає в тому, що вся програма користувача будується у вигляді набору Співпрограма (coroutine), які працюють під управлінням загального монітора. Природно, що в моніторі підтримуються контексти всіх Співпрограма, але і монітор, і співпрограми є складовими одного користувача процесу, якому відповідає один ядерна нитку. Звичайно, з використанням користувацьких ниток неможливо досягти реального розпаралелювання програми. Єдиний реальний ефект, якого можна домогтися, полягає в можливості розпаралелювання обмінів при використанні асинхронного режиму системних викликів. Як вважають деякі фахівці (до числа яких не відноситься автор цієї частини курсу), основна перевага використання користувацьких ниток полягає в кращій структуризації програми. Методологія застосування легковагих процесів

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

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

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

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

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

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

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

Основний неприємністю традиційних файлових систем було хаотичне розподіл зовнішньої пам'яті. Один блок зовнішньої пам'яті файлу міг відстояти на довільну кількість циліндрів, тобто елементів пересування головок. Корінний перелом стався у так званої "швидкої файлової системі ", розробленої Кирком МакКусіком в рамках проекту BSD 4.3. МакКусік вирішив, що краще головок магнітного диска рухатися не дуже сильно. Тому було введено поняття групи магнітних циліндрів, в межах яких повинен розташовуватися файл. Замість довільного пересування магнітних головок в масштабі всієї поверхні диска для послідовного читання файлу потрібно обмежене зміщення головок у виділеній групі циліндрів. Але це не вирішує всіх проблем.

З'явилися пристрої з магнітними дисками, що пред'являють зовнішнього світу інтерфейс з 24 магнітними голівками в той час, коли насправді (фізично) їх було 15. І що ж тепер оптимізується? Апаратура та вбудоване програмне забезпечення контролерів магнітних дисків самі проводять власну оптимізацію, а файлова система вважає, що все вже оптимізовано. Ще гірше справи стали з появою дискових масивів, особливо починаючи з п'ятого рівня організації. RAID забезпечує надійне зберігання даних з 90-відсотковою гарантією і розділене зберігання блоку даних на всіх дисках, що входять до масив. Що ж тепер оптимізують операційна система по відношенню до доступу до файлів? Це одна з основних проблем сучасних файлових систем; вона не вирішена, і не зрозуміло, чи буде вирішена найближчим часом. Тим не менше, файлові системи розвиваються, і ми далі наведемо огляд найцікавіших існуючих файлових систем (зі світу UNIX) і деякі приклади перспективних файлових систем. Поширені файлові системи

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

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

Кожен каталог і файл файлової системи має унікальне повне ім'я (в ОС UNIX це ім'я прийнято називати full pathname - ім'я, що задає повний шлях, поскільки воно дійсно задає повний шлях від кореня файлової системи через ланцюжок каталогів до відповідного каталогу або файлу; ми будемо використовувати термін "повне ім'я", оскільки для pathname відсутній милозвучна російський аналог). Каталог, що є коренем файлової системи (кореневий каталог) в будь-якої файлової системи має визначене ім'я "/" (слеш). Повне ім'я файлу, наприклад,/bin/sh означає, що в кореневому каталозі має міститися ім'я каталогу bin, а в каталозі bin повинно міститися назва файлу sh. Коротким або відносним ім'ям файлу (relative pathname) називається ім'я (можливо, складеного), що задає шлях до файлу починаючи від поточного робочого каталогу (сущес?? яття команда і відповідний системний виклик, що дозволяють встановити поточний робочий каталог.

У кожному каталозі містяться два спеціальних імені, ім'я ".", що іменує сам цей каталог та ім'я "..", що іменує "батьківський" каталог даного каталогу, тобто каталог, що безпосередньо передує даному в ієрархії каталогів.

UNIX підтримує численні утиліти, що дозволяють працювати з файловою системою і доступні як команди командного інтерпретатора. Ось деякі з них (найбільш уживані):  cp      імя1 імя2 - копіювання файлу      імя1 в файл імя2  rm      імя1 - знищення файлу імя1  mv      імя1 імя2 - перейменування      файлу імя1 в файл імя2  mkdir      ім'я - створення нового каталогу      ім'я  rmdir      ім'я - знищення каталогу ім'я  ls      ім'я - видача вмісту      каталозі ім'я  cat      ім'я - видача на екран      вмісту файлу ім'я  chown      ім'я режим - зміна режиму      доступу до файлу

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

У світі UNIX існує кілька різних видів файлових систем зі своєю структурою зовнішньої пам'яті. Найбільш відомі традиційна файлова система UNIX System V (s5) і файлова система сімейства UNIX BSD (ufs). Файлова система s5 складається з чотирьох секцій (малюнок 6.1 (a)). У файловій системі ufs на логічному диску (розділі реального диска) знаходиться послідовність секцій файлової системи.

Коротко опишемо суть і призначення кожної області диска:  Boot-блок містить програму розкрутки, яка служить для      первісного запуску ОС UNIX. У файлових системах s5 реально      використовується boot-блок тільки кореня. У додаткових      файлових системах ця область присутній, але не використовується.

Рис. 6.1.  Суперблоки - це найбільш відповідальна область файлової системи,      що містить інформацію, яка необхідна для роботи з файловою системою в      цілому. Суперблоки містить список вільних блоків і вільні i-сайти      (information nodes - інформаційні вузли). У файлових системах usf для      підвищення стійкості підтримується кілька копій суперблоку (як      видно з малюнка 6.1 (b), по одній копії на групу циліндрів). Кожна копія      суперблоку має розмір 8196 байт, і лише одна копія суперблоку використовується      при монтуванні файлової системи (див. нижче). Однак, якщо при      монтуванні встановлюється, що первинна копія суперблоку пошкоджена      або не задовольняє критеріям цілісності інформації, використовується      резервна копія.  Блок групи циліндрів містить число i-вузлів, специфіковані в      списку i-вузлів для даної групи циліндрів, і число блоків даних, які      пов'язані з цими i-вузлами. Розмір блоку групи циліндрів залежить від розміру      файлової системи. Для підвищення ефективності файлова система ufs      намагається виділяти i-вузли і блоки даних в одній і тій же групі      циліндрів.  Список i-вузлів (ilist) містить список i-вузлів, відповідних      файлів даної файлової системи. Максимальне число файлів, які можуть      бути створені в файлової систем, визначається числом доступних i-вузлів. У      i-сайті зберігається інформація, що описує файл: режими доступу до файлу,      час створення та останньої модифікації, ідентифікатор користувача та      ідентифікатор групи творця файлу, опис блокової структури файлу і      т.д.  Блоки даних - у цій частині файлової системи зберігаються реальні      дані файлів. У разі файлової системи ufs всі блоки даних одного файлу      намагаються розмістити в одній групі циліндрів. Розмір блоку даних      визначається при форматуванні файлової системи командою mkfs і може      бути встановлений в 512, 1024, 2048, 4096 або 8192 байт.

Файли будь-якої файлової системи стають доступними тільки після "монтування" цієї файлової системи. Файли "не змонтованої "файлової системи не є видимими операційною системою.

Для монтування файлової системи використовується системний виклик mount. Монтування файлової системи означає наступне. У наявною на момент монтування дереві каталогів і файлів повинен бути листовий вузол - порожній каталог (у термінології UNIX такий каталог, який використовується для монтування файлової системи, називається directory mount point - точка монтування). У будь-якій файловій системі є кореневий каталог. Під час виконання системного виклику mount кореневий каталог монтуємий файлової системи поєднується з каталогом - точкою монтування, в результаті чого утворюється нова ієрархія з повними іменами каталогів і файлів.

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

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

Ядро ОС UNIX підтримує для роботи з файлами кілька системних викликів. Серед них найбільш важливими є open, creat, read, write, lseek та close.

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

Файл у системних викликах, що забезпечують реальний доступ до даних, ідентифікується своїм дескриптором (цілим значенням). Дескриптор файлу видається системними викликами open (відкрити файл) і creat (створити файл). Основним параметром операцій відкриття і створення файлу є повне або відносне ім'я файлу. Крім того, при відкритті файлу вказується також режим відкриття (тільки читання, тільки запис, запис і читання і т.д.) і характеристика, що визначає можливості доступу до файлу: open (pathname, oflag [, mode])

Однією з ознак, які можуть брати участь в параметрі oflag, є ознака O_CREAT, наявність якого вказує на необхідність створення файлу, якщо під час виконання системного виклику open файл з вказаним ім'ям не існує (параметр mode має сенс тільки при наявності цієї ознаки). Тим не менше з історичних причин і для забезпечення сумісності з попередніми версіями ОС UNIX окремо підтримується системний виклик creat, що виконує практично ті ж функції.

Відкритий файл може використовуватися для читання і запису послідовностей байтів. Для цього підтримуються два системних виклику: read (fd, buffer, count) і write (fd, buffer, count)

Тут fd - дескриптор файлу (отриманий при раніше виконаному системному виклик open або creat), buffer - покажчик символьного масиву і count - число байтів, які повинні бути прочитані з файлу або до нього записані. Значення функції read або write - ціле число, яке таке саме, як count, якщо операція закінчується успішно, дорівнює нулю при досягненні кінця файлу і негативно при виникненні помилок.

У кожному відкритому файлі існує поточна позиція. Відразу після відкриття файл позиціонується на перший байт. Іншими словами, якщо відразу після відкриття файлу виконується системний виклик read (або write), то будуть прочитані (або записані) першу count байт вмісту файлу (звичайно, вони будуть успішно прочитані лише в тому випадку, якщо файл реально містить принаймні count байт). Після виконання системного виклику read (або write) покажчик читання/запису файлу буде встановлений в позицію count 1 і т.д.

Такий чисто послідовний стиль роботи виявляється в багатьох випадках достатнім, але часто буває необхідно читати або змінювати файл з довільною позиції (наприклад, як без такої можливості зберігати у файлі прямо індексовані масиви даних?). Для чіткого позиціонування файлу служить системний виклик lseek (fd, offset, origin)

Як і раніше, тут fd - дескриптор раніше відкритого файлу. Параметр offset задає значення відносного зміщення покажчика читання/запису, а параметр origin вказує, щодо якої позиції повинно застосовуватися зсув. Можливі три значення параметра origin. Значення 0 вказує, що значення offset повинно розглядатися як зміщення відносно початку файлу. Значення 1 означає, що значення offset є зсувом щодо поточної позиції файлу. Нарешті, значення 2 говорить про те, що задається зсув щодо кінця файлу. Зауважимо, що типом даних параметра offset є long int. Це означає, що, по-перше, можуть здаватися досить довгі зсуву і, по-друге, зміщення можуть бути позитивними і негативними.

Наприклад, після виконання системного виклику lseek (fd, 0, 0)

покажчик читання/запису відповідний файл буде встановлений на початок (на перший байт) файлу. Системний виклик lseek (fd, 0, 2)

встановить вказівник на кінець файлу. Нарешті, виконання системного виклику lseek (fd, 10, 1)

призведе до збільшення поточного значення вказівника на 10.

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

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

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

Файлові системи з журналізацію поділяються на дві категорії: системи, які виробляють журналізацію всіх змін, і системи, журналізующіе тільки зміни метаданих. Серед систем другої категорії виділяються ті, які журналізуют тільки виділену деяку інформацію (наприклад, не поміщають в журнал інформацію про зміну власника файлу).

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

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

Є два типи журналів: журнал, орієнтований тільки на повторне виконання операцій (redo-only), і журнал, здатний підтримувати як повторне виконання операцій, так і їх зворотне виконання (undo-redo). У журналі "undo-redo" зберігаються як нові, так і старі значення даних. При використання журналу типу "redo-only" операції відновлення спрощуються, але потрібно обмежувати порядок запису метаданих до журналу і на місце їх постійного зберігання. Журнал "undo-redo" більше за обсягом і вимагає застосування більш складного механізму журналізацію, але використання цього типу журналізацію допускає більш високий рівень паралельності.

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

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

Найбільш відомою файловою системою, заснованою виключно на журналізацію і журналізующей всі зміни, є BSD-LFS (UNIX BSD 4.4 Log-Structured File System). Серед файлових систем, що підтримують журналізацію тільки метаданих, можна виділити Cedar, Calaveras і Veritas.