Предотвращение повреждения данных на диске ext4 / Linux при потере питания

У меня есть несколько встроенных плат, работающих под управлением американской системы Megatrends со встроенным linux в качестве ОС. Проблема, с которой я столкнулся, заключается в том, что промышленные вспышки будут повреждены при отключении питания. Я их отформатировал как ext4. Когда бы это ни происходило, я обычно могу исправить флеш с помощью fsck, но это не будет возможно в наших развертываниях. Я слышал, что отключение кэширования записи должно помочь, но я не могу понять, как это сделать. Кроме того, есть что-то еще, что я должен сделать?

Больше информации

Накопитель представляет собой флэш-модуль 4 Гб ide. У меня есть один раздел, который ext4. На этом разделе установлена ​​ОС, а grub - мой загрузчик.

fdisk -l показывает / dev / sda как мой флэш-модуль с / dev / sda1 в качестве основного раздела.

После потери питания я обычно не могу сделать это полностью через сценарии начальной загрузки.

Когда я монтирую диск на другом ПК, я запускаю fsck / dev / sda1. Это всегда показывает сообщения, как

"zero datetime on node 1553 ... fix (y)?"

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

Когда я доберусь до офиса завтра, я опубликую фактический вывод fdisk -l

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

Вот вывод из dumpe2fs

#sudo dumpe2fs /dev/sda1
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   VideoServer
Last mounted on:          /
Filesystem UUID:          9cba62b0-8038-4913-be30-8eb211b23d78
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              245760
Block count:              977949
Reserved block count:     48896
Free blocks:              158584
Free inodes:              102920
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      239
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Fri Feb  4 15:12:00 2011
Last mount time:          Sun Oct  2 23:48:37 2011
Last write time:          Mon Oct  3 16:34:01 2011
Mount count:              2
Maximum mount count:      26
Last checked:             Tue Oct  4 07:44:50 2011
Check interval:           15552000 (6 months)
Next check after:         Sun Apr  1 07:44:50 2012
Lifetime writes:          21 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      249d2b79-1e20-49a3-b324-6cb631294a63
Journal backup:           inode blocks

Кэш записи обычно не имеет ничего общего с BIOS, в основном там нет возможности переключать настройки дискового кэша. С Linux, использование hdparm -W 0должно помочь.

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

Кстати, я бы поддержал идею о недоступной для записи корневой файловой системе (чтобы ваша система могла загружаться в своего рода «режиме восстановления» и обеспечивать удаленный доступ, даже если записываемая файловая система по какой-то причине не монтируется). И если вы можете изменить конструкцию аппаратного обеспечения, рассмотрите возможность использования устройств mtd вместо дисков IDE / SATA с файловой системой с поддержкой флэш-памяти, такой как jffs2 . Мы использовали эту комбинацию с несколькими встроенными устройствами (в основном это решения для VPN-маршрутизаторов в полевых условиях) в течение нескольких лет с хорошими результатами.

Обновление: корень вашей проблемы, кажется, в том, что вы используете файловую систему ext4 с отключенным ведением журнала - has_journalотсутствует в Filesystem featuresсписке. Просто закройте все сервисы, проверьте, использует ли что-то открытые файлы lsof +f -- /, перемонтируйте ваш корневой раздел только для чтения mount -o remount,ro /, включите журнал с помощью tune2fs -O has_journal /dev/sda1и установите режим «упорядоченного» журнала в качестве опции монтирования по умолчанию с помощью tune2fs -o journal_data_ordered /dev/sda1- вам придется повторно запустите fsck (желательно из спасательной системы) и переустановите root / reboot после этой операции.

С этими настройками метаданные гарантированно будут восстановлены из журнала даже в случае внезапного сбоя питания. Фактические данные также постоянно записываются на диск, хотя вы можете увидеть данные за несколько секунд до потери питания при загрузке. Если это неприемлемо, вы можете рассмотреть возможность использования tune2fs -o journal_data /dev/sda1опции монтирования с вашей файловой системой - это будет включать в себя все данные, записанные на диск в журнале - это, очевидно, даст вам лучшую согласованность данных, но за счет снижения производительности и более высокого уровня износа на вашем SSD.

Предложение кеша записи - хорошее начало, но это звучит как недостаток архитектурного дизайна. Во встроенной системе внутренняя вспышка, вероятно, НЕ должна быть установлена ​​R / W, за исключением редких случаев. Вы действительно должны выполнять большую часть работы в файловой системе памяти и синхронизировать изменения обратно во флэш-память RW по какой-то пользовательской команде или через определенный интервал. Для встроенной системы очень редко использовать обычную файловую систему (например, ext4) в режиме rw во время нормальной работы. Если есть какие-то требования к приложениям, когда вам нужно много места для хранения, вы должны рассмотреть возможность изменения системного раздела и его разработки таким образом, чтобы раздел данных мог быть fsck -y'ed как часть запуска.

Если вам нужны какие-то отправные точки, я бы посмотрел, как люди настраивают бездисковые системы Linux:

http://frank.harvard.edu/~coldwell/diskless/

и начать оттуда. Основная идея заключается в том, что ваши системные двоичные файлы и данные могут быть смонтированы только для чтения, чтобы ваша файловая система не была повреждена. Однако вам нужно иметь возможность писать в определенные области, поэтому вам нужно что-то, чтобы обычно хранить файловую систему / tmp, / var / tmp. Даже если некоторые вещи должны быть доступны для записи, вы просто создаете скрипт для монтирования раздела как r + w и затем фиксируете изменения, а затем возвращаетесь в режим только для чтения.

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