У меня есть несколько встроенных плат, работающих под управлением BIOS American Megatrends со встроенным Linux в качестве ОС. У меня проблема в том, что промышленная флеш-память будет повреждена при отключении питания. Я их отформатировал как ext4. Когда это происходит, я обычно могу исправить флеш-память с помощью fsck, но в наших развертываниях это будет невозможно. Я слышал, что отключение кэширования записи должно помочь, но я не могу понять, как это сделать. Кроме того, что мне еще нужно сделать?
Больше информации
Привод представляет собой флеш-модуль ide 4 ГБ. У меня есть один раздел - ext4. O.S. установлен на этом разделе, а 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 / перезагрузить после этой операции.
Благодаря этим настройкам, метаданные гарантированно можно будет восстановить из журнала даже в случае внезапного сбоя питания. Фактические данные также постоянно записываются на диск, хотя вы можете увидеть данные за несколько секунд до отключения электроэнергии при загрузке. Если это неприемлемо, вы можете рассмотреть возможность использования 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, и всякий раз, когда вы вносите изменения в конфигурацию, вы должны запускать сценарий сохранения, который фактически повторно объединяет конфигурации и записывает их во флэш-память.