Зміст
Ефективне використання легковагих процесів у симетричних мультипроцесорах
Контекст процесу
Ядерні нитки
Користувальницькі легковагі процеси
Користувальницькі нитки
Методологія застосування легковагих процесів
Сучасні файлові системи
Обмеження традиційних файлових систем
Поширені файлові системи
Файлові системи з журналізація
Ефективне використання легковагих процесів у симетричних мультипроцесорахПідтримувані в сучасних операційних системах (зокрема, в ОС 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.