私は、OSとしてlinuxを組み込んだAmerican Megatrends biosを実行しているいくつかの組み込みボードを持っています。私が抱えている問題は、産業用フラッシュIDEが電力損失で破損することです。私はそれらをext4としてフォーマットしています。これが発生するときはいつでも、通常はfsckでフラッシュを修正できますが、私たちの展開ではこれは不可能です。書き込みキャッシュを無効にすると効果があると聞きましたが、その方法がわかりません。また、他に何かすべきことはありますか?
詳細
ドライブは4GB IDEフラッシュモジュールです。 ext4のパーティションが1つあります。 O.S.そのパーティションにインストールされ、grubが私のブートローダーです。
fdisk -lは、/ dev/sdaをフラッシュモジュールとして表示し、/ dev/sda1をプライマリパーティションとして表示します。
停電後は、通常、起動初期化スクリプトでは完全に解決できません。
ドライブを別のPCにマウントすると、 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がない場合は、別のシステムでディスク書き込みキャッシュを無効にして、ディスクを再接続できるはずです。
ところで、筆者は書き込み不可のルートファイルシステムのアイデアをもう1つ紹介します(システムが一種の「回復モード」で起動し、書き込み可能なファイルシステムが何らかの理由でマウントできない場合でもリモートアクセスを許可します)。また、ハードウェア設計を変更できる場合は、 jffs2 のようなフラッシュ対応のファイルシステムを備えたIDE/SATAディスクの代わりに mtd devices の使用を検討してください。この組み合わせを複数の組み込みデバイス(主にフィールドの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を(できればレスキューシステムから)再実行し、この操作の後にルートを再マウント/再起動する必要があります。
これらの設定を行うと、突然の電源障害が発生した場合でも、メタデータをジャーナルから回復できることが保証されます。実際のデータも一貫してディスクに書き込まれますが、起動時に停電が失われるまでに数秒のデータが表示される場合があります。これが許容できない場合は、ファイルシステムでtune2fs -o journal_data /dev/sda1
マウントオプションを使用することを検討してください。これにより、ジャーナルのディスクに書き込まれたすべてのデータが含まれます。これにより、データの一貫性が向上しますが、パフォーマンスが低下し、摩耗が増加します。 SSDのレベル。
書き込みキャッシュの提案は良い出発点ですが、これはアーキテクチャの設計上の欠陥のように聞こえます。組み込みシステムでは、まれな状況を除いて、内蔵フラッシュをR/Wにマウントしないでください。実際には、ほとんどの作業をメモリファイルシステムで実行し、ユーザーコマンドまたは定期的な間隔で変更をRWフラッシュに同期させる必要があります。組み込みシステムが通常の操作中にrwモードで通常のファイルシステム(ext4など)を使用することは非常にまれです。大量のストレージスペースが必要なアプリケーション要件がある場合は、システムパーティションを異なるものにして、データパーティションを起動の一部としてfsckできるように設計することを検討してください。
出発点が必要な場合は、ディスクレスLinuxシステムのセットアップ方法を見てみましょう。
http://frank.harvard.edu/~coldwell/diskless/
そこから始めましょう。一般的な考え方は、システムのバイナリとデータを読み取り専用でマウントできるため、ファイルシステムが破損しないということです。ただし、特定の領域に書き込むことができるようにする必要があるため、通常はメモリファイルシステム/ tmp、/ var/tmpに何かが必要です。特定のものが書き込み可能である必要がある場合でも、パーティションをr + wとしてマウントするスクリプトを作成し、変更をコミットしてから、読み取り専用に戻ります。
これの非常に優れた例は、Cycladesハードウェアとその組み込みLinuxです。構成を変更するたびに、実際に構成を再バンドルしてフラッシュに書き込む保存スクリプトを実行する必要があります。