Який варіант монтажу використовувати для файлової системи ext3, щоб мінімізувати втрату даних або пошкодження?

У мене є вбудована установка з використанням initramfs для кореневої файлової системи, але за допомогою користувацького розділу ext3, встановленого на компактному флеш-накопичувачі IDE. Оскільки цілісність даних перед втратою електроенергії є найважливішим фактором у всій установці, я використовував наступні параметри для монтажу (нижче - запис із мого /etc/fstabфайлу

<file system> <mount pt> <type> <options>                         <dump><pass>
/dev/sda2     /data      ext3   auto,exec,relatime,sync,barrier=1 0     2

Мені прийшли ці варіанти з читання в Інтернеті. Мене хвилює те, що зміст /proc/mountsнадає наступне:

/dev/sda2 /data ext3 rw,sync,relatime,errors=continue,user_xattr,acl,
barrier=1,data=writeback 0 0

З того, що я розумію, читаючи навколо, - це те, що я хочу використовувати data=journalпараметр для монтажу, оскільки це забезпечує найкращий захист від пошкодження даних. Однак на сторінці man для конкретних опцій ext3 на mountньому написано наступне про варіант запису:

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

Я дуже збентежений з цього приводу - сторінка man, здається, пропонує зробити те, що для цілісності файлової системи я хочу вказати data=writebackваріант, mountале більшість інших знайдених нами посилань (включаючи деякі опубліковані книги на вбудованому Linux) пропонують мені використовувати data=journal. Який для мене найкращий підхід використовувати? Швидкість запису зовсім не проблема - цілісність даних є.

Не вводить в оману той факт, що лише writebackзгадує internal filesystem integrity.
Якщо метадані файлової системи ext3ви використовуєте journal, orderedчи writebackзавжди, вони завжди реєструються, і це означає внутрішню цілісність файлової системи.

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

Отже, якщо цілісність даних є вашою основною турботою, а швидкість не важлива, data=journalце шлях.

Як ви вже помітили, головне - це те, що ви не можете запобігти всій системі збоїв.

Що ви можете зробити:

1. Що стосується програмного забезпечення, ви можете використовувати fdatawrites після кожної важливої ​​операції (Дивіться цю публікацію 2003 року від Теодора Т'со, головного розробника Linux FS Kernel. Це все-таки правда. Є також ця велика втрата даних, прихована в старих версіях ext4)
2. Скоротіть інтервал комісій до 1 секунди ( фік = 1 ) (див. Цю статтю з LWN, мова йде про ext4, але містить дійсно корисну інформацію про ext3). NB: Це не повинно бути потрібним при синхронізації .
3. Як сказав RHEL doc, на який вказує sim, використовуйте * data_err = перервати *, а дані = замовити
4. час роботи скоротить марні операції над файловою системою
5. Як ви вже помітили, barrier = 1 - це хороший спосіб мінімізувати втрату даних (див. Цю публікацію )
6. І синхронізація - це, звичайно, одна з опцій "Я не хочу втрачати свої дані".

Зрештою, паранояльні варіанти кріплення можуть виглядати так:

auto,exec,relatime,sync,barrier=1,commit=1,data=ordered,data_err=abort,noatime,

Ви також можете забезпечити цілісність даних за допомогою автоматичного fsck при кожному завантаженні.

Спробуйте змінити ту частину чоловічої сторінки, яку ви промальовуєте:

зворотний запис

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

Як зазначив don_crissti, інші режими не мають "проте".