«Безопасная» конфигурация ext4 для систем, работающих без присмотра

У меня есть система под управлением Linux, которая должна работать без присмотра в течение длительного времени. Система использует промышленную CF-карту для хранения. В большинстве случаев нет записи во флэш-память, хотя время от времени некоторые данные / настройки конфигурации могут быть изменены. Система должна быть устойчивой к сбоям питания.

Я хотел бы использовать ext4 для этого. Каков наилучший способ настроить ext4 для такого рода настройки? Учитывая, что:

• Производительность вообще не проблема (особенно производительность записи)
• При отключении питания система всегда должна загружаться в чистом состоянии, даже если это означает, что данные, записанные за последние несколько секунд, будут потеряны
• Если можно избежать fsck, то тем лучше.

(Мне известен этот связанный вопрос: предотвратить повреждение данных на диске ext4 / Linux при потере питания )

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

Мое решение состояло в том, чтобы создать систему initramfs на основе Gentoo, содержащую только папку rw для приложений и конфигураций (этот подход используется всеми поставщиками маршрутизаторов / брандмауэров). Это решение добавляет дополнительный уровень сложности при работе с обновлениями системы, но уверяет вас, что система будет ВСЕГДА загружаться.

Что касается вашего конкретного вопроса, вы должны оставить журнал EXT4 включенным, чтобы иметь более быстрый fsck (из нескольких секунд), использовать опцию data = journal mount, уменьшить опцию commit или использовать синхронизацию, чтобы буферы всегда оставались пустыми.

Ссылки: http://www.kernel.org/doc/Documentation/filesystems/ext4.txt

Я предвосхищу это, сказав, что для меня EXT (во всех его воплощениях) - довольно ужасная файловая система - я видел более « интересные » случаи повреждения файловой системы в относительно небольшом количестве Linux / EXT {2,3,4} систем, которые я администрировал, чем у меня, в относительно большом количестве файловых систем Not-EXT, которые мне приходилось использовать.
Если это вообще возможно, попытайтесь выбрать более надежную файловую систему. Вы будете благодарны, когда произойдет неизбежное.

Как говорится, и все мои личные предубеждения в открытую и отодвинутые, EXT4 имеет три функции, которые я могу придумать, которые могут вам помочь:

• Журналирование
  EXT4 может быть журнальной файловой системой, если вы этого хотите. Включите функцию ведения журнала (и, в частности, установите режим ведения журнала данных journalчерез tune2fsили в качестве опции монтирования).
  Это влечет за собой снижение производительности, так как все данные должны быть записаны в журнал EXT, прежде чем они будут «зафиксированы» в файловой системе (каждая запись в основном происходит дважды), но это гарантирует, что вы всегда сможете восстановиться настолько, насколько воспроизведение журнала получит вас без каких-либо проблемы.

• SYNChronous Mounts
  Если безопасность имеет первостепенное значение, монтировать файловую систему с помощью этой syncопции всегда хорошая идея. Это немедленно заставляет все записи на диск - опять же, это снижение производительности, но это хорошая идея, если вы ожидаете, что сбои питания или случайные незнакомцы выдергивают CF-карту.

• Максимально ограничьте доступные для записи файловые системы. Эта система не является специфичной для EXT, но слишком распространенная философия Linux, заключающаяся в том, что «просто создайте один большой корневой раздел и поместите в него все», откровенно говоря, глупа . Создайте правильную структуру файловой системы ( /, /var, /usr, /homeи т.д. ...), и установить , как многие файловые системы только для чтения , как это возможно.
  Раньше это был общий совет для систем Unix в целях безопасности, но в вашем случае это дает дополнительное преимущество: вы не можете повредить файловую систему, если не можете записать в нее.

EXT4 не звучит как лучший выбор для вашей системы; Я бы предложил посмотреть на файловую систему с лог-структурой. Они работают, обрабатывая данные как постоянный поток обновлений записи для виртуального потока с указателем, который указывает на последнюю «голову». Обновления происходят путем записи данных и метаданных в хранилище, а затем обновления указателя. В случае сбоя после записи, но до обновления указателя последние данные теряются, но файловая система работает согласованно.

Двумя файловыми системами-кандидатами являются LogFS и NILFS . Оба доступны в основном ядре Linux.

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

Ext4 (и семейство) - это прекрасная файловая система общего назначения с (я думаю) многими миллиардами часов использования на различном оборудовании и вариантах использования. Однако то, что вы просите, не совсем подходит для ext4. Указатели от voretaq7 и Giovanni помогут извлечь максимальную пользу из использования ext4, если вам нужно, но реальный ответ - использовать что-то более подходящее вашим требованиям. Стив дал вам пару вариантов. Если вы продолжите получать мощность от ext4 FS, вы в конечном итоге получите беспорядок.

Если вы создаете единую систему, вы должны сделать выбор - использовать что-то более подходящее или признать, что в какой-то момент будут проблемы. Это может быть только 1 отключение питания из 100 или 1 из 1000. Это может быть достаточно для того, чтобы вы рискнули, и устройство может работать в течение длительного времени (лет) без какого-либо ручного вмешательства.

Если это продукт, который вы собираетесь широко распространять / выводить на рынок, у вас есть выбор - использовать что-то более подходящее. Или вы принимаете бизнес-решение для поддержки некоторого процента устройств, которые будут блокироваться каждый год, и для их восстановления потребуется либо замена, либо ручное вмешательство.