Какой вариант монтирования использовать для файловой системы ext3, чтобы минимизировать потерю или повреждение данных?

У меня есть встроенная установка, использующая initramfs для корневой файловой системы, но использующая пользовательский раздел ext3, смонтированный на компактном флеш-накопителе. Поскольку целостность данных перед лицом потери питания является наиболее важным фактором во всей настройке, я использовал следующие параметры для монтирования (ниже приведена запись из моего /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опцию для моего монтирования, поскольку это обеспечивает наилучшую защиту от повреждения данных. Тем не менее, со страницы руководства для конкретных опций ext3 для mountнего говорится следующее о опции обратной записи:

Порядок данных не сохраняется - данные могут быть записаны в основную файловую систему после того, как их метаданные были зафиксированы в журнале.
По слухам, это самая высокая пропускная способность. Это гарантирует целостность внутренней файловой системы , однако позволяет старым данным появляться в файлах после сбоя и восстановления журнала.

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

Не вводите в заблуждение тот факт, что только writebackупоминает internal filesystem integrity.
С тем ext3, используете ли вы journal, orderedили writeback, метаданные файловой системы всегда записываются в журнал, что означает целостность внутренней файловой системы.

Эти режимы передачи данных предлагают способ контроля над тем, как обычный данные записываются в файловой системе.
В writebackрежиме изменения метаданных сначала записываются в журнал, а блок фиксации записывается. После обновления журнала могут продолжаться метаданные и записи данных. data=writeback может представлять серьезную угрозу безопасности: если происходит сбой системы при добавлении в файл, после фиксации метаданных (и выделения дополнительных блоков данных), но до записи данных (блоки данных перезаписываются новыми данными), после журнала восстановление этого файла может содержать блоки, заполненные данными из ранее удаленных файлов - от любого пользователя ¹ .

Таким образом, если целостность данных является вашей главной задачей, а скорость не важна, data=journalэто путь.

Как вы уже заметили, главное в том, что вы не можете предотвратить сбои файловой системы.

Что ты можешь сделать:

1. Что касается программного обеспечения, то вы можете использовать fdatawrites после каждой важной операции (см. Этот пост 2003 года от Теодора Тсо, главного разработчика ядра Linux FS. Это по-прежнему верно. Также есть одна статья о серьезной потере данных, скрытой в более старых версиях ext4)
2. Уменьшите интервал коммита до 1 секунды ( commit = 1 ) (см. Эту статью из LWN, она о ext4, но содержит действительно полезную информацию о ext3). NB: Это не должно быть необходимости, с синхронизацией .
3. Как сказал RHEL doc, указанный sim, используйте * data_err = abort * и data = order
4. noatime уменьшит бесполезные операции на файловой системе
5. Как вы уже заметили, барьер = 1 - это хороший способ минимизировать потерю данных (см. Этот пост )
6. И синхронизация также, конечно, является одной из опций «Я не хочу потерять свои данные».

В конце, варианты подключения параноика могут выглядеть следующим образом:

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

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

Попробуйте изменить часть справочной страницы, которую вы указали:

обратная запись

Порядок данных не сохраняется - данные могут быть записаны в основную файловую систему после того, как их метаданные были зафиксированы в журнале. По слухам, это самая высокая пропускная способность. Это гарантирует целостность внутренней файловой системы, однако позволяет старым данным появляться в файлах после сбоя и восстановления журнала.

Как указывал don_crissti, другие режимы не имеют «однако».