組み込みLinux用の破損防止SDカードファイルシステム？

最近、お客様にかなり不快な状況がありました-リモートセンシングデータの表示に使用されるRaspberry Piベースの「キオスク」ファイルシステムの破損。Ext4、マニュアルfsckが必要です。システムは明日の重要なプレゼンテーションの一部となり、すぐにサービスが必要になります。もちろん、夜間に電源を切るときにシステムをうまくシャットダウンするように顧客に要求することはできません。システムは単純にそのような虐待に耐えなければなりません。

将来はそのような状況を避けたいので、これを防ぐファイルシステムにOSを移動したいと思います。MTDデバイス向けのファイルシステムがたくさんあります。SDカード（標準ブロックデバイス）で実行するには、深刻なフープジャンピングが必要です。破損に対する優れた耐性を誇る他のファイルシステム（ジャーナリングなど）もあります。私はまだ彼らの賛否両論の合理的な比較を見なければなりません。

Linuxで利用可能なファイルシステムは、予期しない停電時の破損に対する最高の耐性を提供し、SDにインストールするためにyaffs2のような不可能なフープをジャンプする必要はありません。

摩耗バランスはプラスですが、要件ではありません。SDカードは通常、完璧ではない場合、独自のメカニズムを備えていますが、システムは「フラッシュにやさしい」必要があります（NTFSなどのシステムは1か月以内にSDカードを殺すことができます）。

単一のSDカードの破損に対する最良の耐性は、事前定義された期間ごとに自動スクラブを実行するRAID1モードのBTRFSによって提供されます。

メリット：

1. ファイルシステムにRWする機能を保持
2. 透過的な圧縮やスナップショットなど、RPiに非常に便利なオプションを備えた、最新のフル機能のファイルシステム
3. （特に）フラッシュメモリを念頭に置いて設計されています

方法は次のとおりです。

ArchARM linuxでRaspberryPiを実行し、カードがSDリーダーにあるため、他のディストリビューションおよび/ devインターフェイスに合わせてこれらの手順を適宜変更します。

パーティションレイアウトの例を次に示します。

/dev/mmcblk0p1: fat32 boot partition
/dev/mmcblk0p2: to be used as btrfs partition
/dev/mmcblk0p3: to be used as btrfs partition (mirrored with the above)
/dev/mmcblk0p4 (optional): swap

btrfsをRAID1に追加するには、次のようにファイルシステムを作成します。

mkfs.btrfs -m raid1 -d raid1 /dev/mmcblk0p2 /dev/mmcblk0p3

次にrsync -aAXv、以前にバックアップしたシステムに移動します。

raid1のBTRFSから起動するには、initramfsを変更する必要があります。したがって、古いファイルシステムでシステムを実行している間に次のことを行う必要があります。

Raspberryは通常mkinitcpioを使用しないため、インストールする必要があります。次に、mkinitcpio.confのMODULES配列に「btrfs」を追加し、initramfsを再作成する必要があります

mkinitcpio -g /boot/initrd -k YOUR_KERNEL_VERSION

YOUR_KERNEL_VERSIONの代わりに入力する内容を知るには、次を実行します

ls /lib/modules

カーネルを更新する場合、再起動する前にinitramfsを再作成する必要があります。

次に、RPiのブートファイルを変更する必要があります。

cmdline.txtには、次のものが必要です。

root=/dev/mmcblk0p2 initrd=0x01f00000 rootfstype=btrfs

config.txtに追加する必要があります

initramfs initrd 0x01f00000

すべてを実行してbtrfs RAID1システムを正常に起動したら、systemdタイマー（推奨）またはcron（dcron）を使用して定期的なスクラブ（3〜7日ごと）を設定するだけです。

btrfs scrub start /

ファイルシステム上で実行され、すべてのファイルのチェックサムを比較し、破損が見つかった場合はそれらを修正します（正しいコピーに置き換えます）。

BTRFS RAID1、単一メディア、およびRaspberry Piの組み合わせにより、このかなり不可解なものが作成されます。すべてのピースをまとめるのに時間がかかりましたが、ここにあります。

さまざまな理由から、フラッシュストレージの方が磁気ストレージよりも望ましいですが、このアプリケーションでは、主に可動部分がないために述べます。そうは言っても、「腐敗を防ぐ」ファイルシステムは存在しないと思いますが、堅牢なファイルシステム（ext4が1つ）が存在するほか、破損を軽減するための戦術もあります。

RAMディスク

RPIのイメージがいない場合は持っているものは何もしようとしません（あるいはしようとしなければならない）場合は、ディスクへの書き込みを変更するには、それがないように聞こえる、そしてように作成したルートファイルシステム使用してみてくださいRAMに展開します。ここでの考え方は、ブート時にRAMに展開される圧縮ルートファイルシステムがあるということです。すべての変更はRAMディスクに対して行われるため、SDカードへの書き込みは事実上ゼロであり、ブート時にのみ読み取りが行われます。これにより、ドライブの読み取り/書き込みが削減され、ドライブの寿命が維持されます。これは、CDからLinuxをブートするときに行われることと似ており、Linuxのブート時に最初に発生することの1つです。

別の方法で、読み取り専用のファイルシステムを使用します。SDカードで読み取り/書き込みルートファイルシステムを使用する場合、ラズベリーpiを十分に安定させることはありません。kernel cmdline（ro）でルートをブートするか、システム全体を含むpiggybackでinitramfsを使用することができます。

どちらも私の手作りのビルドシステムOpenADKで作成できます。（http://www.openadk.org）

さて、あなたがここで抱えている問題は、ext *などの「最新の」ファイルシステムを使用すると、SDカードがすり減る可能性が高いことです。1年以内に起こる私の経験から、またはあなたがより高い端を取るならば来年。

問題は、現代のファイルシステムがデータの断片化を防ぐために常にブロックを移動していることです。これは、キャッシュにロードするときにすべてのデータを照合したい回転ディスクでは良いことです。欠点は、多くのI / Oが発生していないときに片付けが処理されているため、キャッシュできない書き込みが増えていることです。

また、多くのロギングを処理するときにも発生します。これは、組み込みデバイスをデバッグするときに行うことができます。ロギング書き込みは最悪の種類の書き込みです。これは、定期的に発生する小さな書き込みが多く、断片化が大量に発生するためです。

システムがセンサーのデータも処理していると言うように、それらが来るとすぐにフラッシュに保存する可能性が非常に高くなります。そして、それらはログデータと同じくらい悪いです。

私はあなたが遭遇しているのと同じ問題に取り組みました、そしてここに私の結論があります。「より堅牢」である、つまり他の書き込みよりも多くの書き込みを処理できるSDカードを探しましたが、SSDのベンチマークとは異なり、それに焦点を合わせた市場でのベンチマークは見つかりませんでした。それらはすべて速度のみに焦点を当てているため、メモリブロックごとの書き込み回数、およびSDCardで使用されている技術を知ることは不可能です。

しかし、私は「工業用」グレードのサンディスクが無名の寿命が長いことに気づきました。それは驚くことではありません、あなたがより多くを支払うとき、あなたはより多くを得ます。

しかし、最終的には、集中ログを有効にすると、寿命が数年を超えるSDカードは見つかりませんでした。

私が思いついた解決策は@BigHomieと@wbx 'の解決策です：読み取り専用のextXファイルシステムを使用します（ジャーナリングが不要になったため、古き良きext2にフォールバックすることさえできます）。セッション内でログを保持したり、一時ファイルを書き込んだりする場合は、いつでもRAMDISKを使用できます。

セッション用に編集できるように、読み取り専用部分内からデータをRAMディスクに取り込むのに役立つチュートリアルとスクリプトのみが存在します。

NB：私の経験では、BeagleboneでAngstrom Linuxを使用し、20台のセンサーデバイスを試用しています。そのシステムのロギングは、systemdのジャーナルシステムを使用して非常に冗長でした。

Linuxは多くのファイルシステムを提供します。ext4は、私が自信を持っているものです。疑わしい場合は、読み書き可能にマウントされるパーティションにext4を使用する必要があります。

ext2ファイルシステムは、はるかに脆弱です。これは、読み取り専用でマウントしたり、正しくマウント解除したりすることができるシステムに最適なファイルシステムです。ただし、ext2の電源障害により破損が発生する可能性が非常に高くなります。

一部のLinuxバージョンではjfsファイルシステムが信頼できない場合でも、もう1つのオプションとしてjfsを検討できます。jfsの場合、ext4よりも破損の可能性は低くなります。Jfsには、クイックマウント時間とファイルシステムチェック時間もあります。