Я задаю це питання від імені іншого користувача, який порушив цю проблему в чаті Ubuntu.
Чи гарантія файлових систем журналу гарантує, що в разі відмови живлення не відбудеться пошкодження?
Якщо ця відповідь залежить від файлової системи, вкажіть, які з них захищають від корупції, а які - ні.
Відповіді:
Гарантій немає. Файлова система журналу більш еластична і менш схильна до корупції, але не захищена.
Весь журнал - це список операцій, які нещодавно були виконані у файловій системі. Найважливіша частина полягає в тому, що запис у журналі робиться до того, як відбудуться операції. Більшість операцій мають кілька кроків. Видалення файла, наприклад, може спричинити за собою видалення запису в таблиці вмісту файлової системи, а потім позначення секторів на диску як вільних. Якщо між двома кроками щось трапиться, файлова система, що перебуває в колі, може негайно повідомити і виконати необхідне очищення, щоб все було послідовно. Це не так у випадку з файловою системою без журналу, яка повинна шукати весь вміст тома, щоб знайти помилки.
Хоча цей журнал набагато менш схильний до корупції, ніж не ведення журналів, корупція все ще може виникнути. Наприклад, якщо вінчестер механічно несправно працює або якщо записи в журнал не спрацьовують або перериваються.
Основна передумова ведення журналу полягає в тому, що, як правило, запис журналу набагато швидше, ніж фактична транзакція, яку він описує. Отже, період між замовленням операційної системи (журналу) запису і жорстким диском, що виконує її, значно коротший, ніж для звичайного запису: більш вузьке вікно, коли все може піти не так, але все ще є вікно.
Ні.
Найбільш поширений тип журналу, який називається журналом метаданих, захищає лише цілісність файлової системи, а не даних. Це включає в себе xfsта ext3/ ext4в data=orderedрежимі за замовчуванням .
Якщо файлова система, яка не веде журнал, зазнає збоїв, вона буде перевірена за fsckдопомогою наступного завантаження. fsckсканує кожну вкладку у файловій системі, шукаючи блоки, позначені як використані, але недоступні (тобто не мають імені файлу) та маркує ці блоки як невикористані. Робити це потрібно багато часу.
За допомогою файлової системи журналу метаданих, замість того, щоб робити fsck, вона знає, які блоки були в середині зміни, тому він може позначити їх як вільні, не шукаючи для них весь розділ.
Існує менш поширений тип журналу, який називається журналом даних, і це те, що ext3робиться, якщо встановити його за допомогою data=journalпараметра.
Він намагається захистити всі ваші дані, записавши не лише список логічних операцій, а й весь вміст кожного запису до журналу. Але оскільки це записування ваших даних двічі, це може бути набагато повільніше.
Як зазначають інші, навіть це не є гарантією, тому що жорсткий диск, можливо, сказав операційній системі, що вона зберігає дані, коли він фактично все ще знаходився в кеші жорсткого диска.
Для отримання додаткової інформації подивіться статтю файлової системи журналу Wikipedia та розділ Режим даних документації ext4 .
data=journalє ця функція взагалі безглуздою?
Файлова система не може гарантувати послідовність своєї файлової системи у разі відмови живлення, оскільки вона не знає, що буде робити апаратне забезпечення.
Якщо жорсткий диск буферизує дані для запису, але повідомляє ОС, що він записав дані і не підтримує відповідні бар'єри для запису, тоді запит поза замовлення може відбуватися, коли попереднє записування не потрапило на платівку, а пізніше має. Додаткову інформацію див. У відповіді на сервер за замовчуванням .
Також положення голови на магнітному жорсткому диску управляється електромагнітами. Якщо в середині запису не вдається живлення, можливо, деякі дані продовжують записуватися під час переміщення головки, пошкоджуючи дані про блоки, які файлова система ніколи не передбачала записувати.
ZFS, яка є близькою, але не зовсім журнальною файловою системою, гарантує дизайн від корупції після відключення електроенергії.
Не має значення, якщо в середині переривається поточне записування, оскільки в такому випадку контрольна сума буде, безумовно, неправильною, тому блок буде ігноруватися. Оскільки файлова система копіюється під час запису, попередні правильні дані (або метадані) все ще знаходяться на диску і замість цього будуть використовуватися.
У більшості випадків відповідь - ні: