Freesource журнальованою - файлові - системи

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

При звичайній роботі файлової системи всі зміни зазвичай відразу виробляються з диском (вірніше з кешем диска в ОС, але це в даному контексті не важливо).

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

Так як після перезавантаження ми не знаємо які операції проводилися, що було незакінчений, а знаємо тільки про те, що диск не був коректно демонтувати (при цьому скидається так званий dirty flag), то нам необхідно проаналізувати файлову систему на всьому диску, і, таким чином, виявити всі помилки в файлової системі і їх виправити. Природно далеко не завжди це можливо виконати автоматично (неприродний інтелект, на жаль, здібностям до ясновидіння поки навчити нікому не вдалося), тому та ж fsck.ext2 після позаштатної перезавантаження може зажадати і ручного втручання.

Ті, хто запускав fsck на розділі в 1 00-200 G (що нині далеко не рідкість) чудово розуміють, що задоволення в цьому мало. Адміністратори ж многотерабайтових масивів, за зайву хвилину простою яких їм можуть «випадково» голову відірвати при слові # 147; fsck # 148; хапаються за валер'янку або просять не лаятися такими словами в їх присутності.

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

Ціна цього задоволення: у нас утворюється невелика (зазвичай вимірюється десятками мегабайт) область диска, на яку припадає максимальне навантаження, тобто максимальне продуктивність, яка вимірюється в кількості i / o операцій в секунду, падає. Ну і, природно, витрачається трохи дискового простору, що в епоху цін на диски <1$/гигабайт никого не волнует.

журнал даних

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

Наскільки мені відомо під Linux журнал даних вміє виконувати лише ext3 з параметром data = journal.

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

Це засіб теж не гарантує збереження даних, однак з мого особистого досвіду використання ext3 з data = journal є найнадійнішою файлової системою.

продуктивність

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

Є два дуже цікавих рішення:
По-перше можна винести журнал на окремий диск (більшість файлових систем це дозволяють), в результаті ми фактично подвоюємо продуктивність додаванням всього одного диска. Це особливо красиво виглядає, коли продуктивність величезного RAID-масиву збільшується таким простим і дешевим способом.

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

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

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

• відкладення створення файлу (в момент створення файла не створювати відразу запис в каталозі, а деякий час тримати її тільки в журналі, можливо файл тимчасовий і буде відразу вилучено);

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

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

недоліки

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

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

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

XFS надходить більш коректно - вона такі блоки прописує нулями. Що часто шокує користувачів. Особливо фанатів reiserfs, яка не стане прописувати нулями.

В результаті reiserfs швидше збереже модифікації, а XFS усіма силами уникне сміття в файлах і витоку даних - просто трохи різні стратегії. Результат один - дані можуть бути загублені, і ви навіть про це не дізнаєтеся. Ще не зіткнетеся з файлом, який вже рік ніхто не чіпав (в архіві лежав), і який раптом виявився забитим сміттям або нулями.

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

По-хорошому всіх цих проблем можна (і потрібно) уникнути просто покупкою UPS, а журнал використовувати краще як додатковий рівень надійності і засіб збільшення продуктивності.

Журнальована файлова система всього лише трохи полегшує адміністрування, однак не є чарівним засобом від втрати даних при нештатних перезагрузках. Тому якщо ви не користуєтеся UPS і не робите Backup, то ваші дані рано чи пізно накриються мідним тазом, чого я вам щиро НЕ бажаю. А якщо захотіти, то можна використовувати журнальованою файлові системи як засіб збільшення продуктивності.