Должен ли я fsck ext3 на встроенной системе?

Question

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

На нашей новейшей платформе мы использовали USB-flash для первоначального производства и теперь переходим на Disk-on-Module для ч / б хранения. Некоторое время назад у нас были некоторые проблемы с файловой системой на многих устройствах, работающих на USB-накопителе, поэтому я включил e2fsck, чтобы посмотреть, поможет ли это. Как выяснилось, мы получили партию плохих флэш-памяти, поэтому, как только они были заменены, проблема исчезла. С тех пор я отключил e2fsck, так как у нас не было никаких признаков того, что это делало систему более надежной, и исторически нам было хорошо без нее.

Теперь, когда мы начали вставлять блоки Disk-on-Module, я снова начал видеть ошибки файловой системы. Внезапно система не может читать / записывать определенные файлы, и если я пытаюсь получить доступ к файлу из аварийной консоли, я просто получаю « Ошибка ввода / вывода ». Я снова включил e2fsck, и все файлы были исправлены.

O'Reilly " Building Embedded Linux Systems " рекомендует запускать e2fsck на файловых системах ext2, но не упоминает об этом по отношению к ext3, поэтому я немного запутался, стоит ли мне его включать или нет.

Как вы относитесь к запуску fsck во встроенной системе? Мы рассматриваем размещение бинарных файлов в разделе ar / o, и только файлы, которые необходимо изменить в разделе ar / w на одном и том же флеш-устройстве, чтобы fsck никогда не мог случайно удалить важные системные файлы, есть ли у кого-нибудь опыт такой настройки (хороший / плохой)

Answer 1

Я думаю, что ответ на ваш вопрос в большей степени относится к тому, какие типы требований к когерентности предъявляются вами к данным. То есть, что должно быть гарантировано в случае потери питания без официального отключения системы? В общем, ни одна из файловых систем типа операционной системы для настольных компьютеров не справляется со всем этим без специального закрытия приложения / синхронизации файлов и очистки дисковых кешей и т. Д. В ключевых точках транзакции в приложении, чтобы обеспечить то, что вам необходимо поддерживать. факт, совершенный в средствах массовой информации.

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

Я согласен, что размещение ваших двоичных файлов или других важных данных только для чтения в отдельном разделе только для чтения помогает гарантировать, что они не могут быть ошибочно выброшены из-за исправления fsck в структурах файловой системы. Как минимум, размещение их в другом подкаталоге вне корневого каталога, в котором хранятся данные R / W, поможет. Но в обоих случаях, если вы поддерживаете обновления программного обеспечения, вам все равно нужно иметь схему, чтобы в любом случае иметь дело с записью областей «только для чтения».

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

Answer 2

Дэйв,

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

Причина в том, что ext3 записывается в журнал. Поэтому, если вы не включите обратную запись (без журнала), то в большинстве случаев ваша таблица метаданных / файловой системы должна синхронизироваться с вашими данными (файлами).

Но, как упоминал Джефф, он не гарантирует уровень над файловой системой. Это означает, что вы все еще получаете «поврежденные» файлы, потому что некоторые записи, вероятно, не были записаны в файловую систему.

Я не уверен, на каком встроенном устройстве вы работаете, но как часто оно перезагружается? Если это контролируемая перезагрузка, вы всегда можете выполнить «sync; sync; sync» перед перезагрузкой.

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

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

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

Надеюсь, это поможет.