☰

堅牢なIoT Linuxデバイスを構成するためのベストプラクティスは何ですか？オーバーレイファイルシステムを使用する必要がありますか？

tag-icon • tag-icon filesystems embedded overlayfs iot
堅牢なIoT Linuxデバイスを構成するためのベストプラクティスは何ですか？オーバーレイファイルシステムを使用する必要がありますか？

過去に、当社はIoTアプリケーションにRaspberry Piを使用していました。問題は、SDカードが磨耗して損傷する可能性があることです。

これで、Debianを実行しているeMMCストレージを含むCompulab SBCを注文しました。

それでは、耐久性のある組み込みIoTデバイスを構成するためのベストプラクティスは何ですか？

私が言う：

  • eMMCストレージを含むSBCを選択してください
  • ジャーナリングファイルシステムがあることを確認してください（has_journalEXT4で有効）。
  • ストレージの磨耗を防ぐためにRAMにログを書き込む（から/etc/systemd/journald.conf Storage=volatile）
  • fsck起動時に実行されていることを確認してください（最後の/etc/fstabフィールドは1または2に設定されています）。
  • スワッピングを無効にする必要があります（実行 - free>総スワップは0でなければなりません）。

もう提案がありますか？

ファイルシステムの上書き

Raspbianには、"raspi-config"->"パフォーマンスオプション"->"ファイルシステムのオーバーライド"にオプションがあります。 Compulabにこのオプションを使用することをお勧めするかどうか尋ねましたが、彼らはすでにファイルシステムログと同じくらい強力だと思い、fsckは実行されています。始めに。オーバーレイファイルシステムを使用してデバイスを複数回再起動してデバイスを無効にし、後で更新しようとしたときに再度有効にする追加の複雑さを考慮する価値のあるストレージへの書き込みを防止していますか？

ベストアンサー1

私はストレージデバイスの耐久性にある程度慣れているので、あなたの最初の質問に答えようとします。

システムのストレージ使用量にアクセスせず、これを改善するための措置を講じないと、SDとeMMCの両方がNANDを使用するため、SDからeMMCに切り替えても状況が改善されない可能性があります。

ストレージに書き込まれるデータ量を推定しましたか？以下を使用してユースケースを評価します。 [詳細は[1]参照]

total bytes written throughout device life = (device capacity in bytes) * (max program/erase cycles) / (write amplification factor)

例えば

  • 1日に0.5GiBを書き込みます。
  • あなたの機器は5年間働くと予想されます。
  • データを書き込んでいるパーティションは合計4GiBです。 （保存容量はこれより大きいが、他のパーティションは読み取り専用です。）
  • MLC（マルチレベルセル）NANDの場合、最大プログラム/削除サイクルは3000です。

これは書き込み増幅素子を提供する。

4*3000/(0.5*365*5) = ~13

書き込み増幅とは何ですか？

SD または eMMC の NAND は NAND ページに記録されます。ホストに1KiB（2つの512バイトセクタ）を書き込むか変更しますが、NANDページは16KiBであるとします。したがって、eMMCコントローラはNANDページ全体を書き込みます。消去を考えると、状況がより複雑になります。 ＮＡＮＤはＮＡＮＤブロックから消去され、ＮＡＮＤブロックは多くのＮＡＮＤページで構成されるからである。

それでは、機器の寿命を延ばすにはどうすればよいですか？

上記の方程式から次のようになります。

  • 装備容量を増やす（ただし、コストが増加する）
  • プログラム/削除サイクルの改善：SLCを選択するか、データ書き込みパーティションをMLCからpSLCに変換します（ただし、これは容量を減らします）。
  • NANDページソートを実行し、ホストでNANDページサイズ（または複数）書き込みを実行し（eMMC EXT_CSD [265]最適書き込みサイズを参照）、eMMCキャッシュの有効化などを実行するようにアプリケーションを改善して書き込み増幅を減らします。

あなたは他の何かをすることができます。

mmc-utils(https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git）またはsysfsを実行し、予期しないエラーが発生する前に必要なアクションを実行してください。

  1. eMMC 拡張 CSD レジスタは以下を提供します。
  • SLCおよびMLCモジュールの寿命を10％単位で予測します。

（0x01 = 0-10％デバイス寿命が終了しました、0x02 = 10-20％、..、0x0B =寿命が終了しました）

タイプ B(MLC): EXT_CSD[268]、タイプ A(SLC): EXT_CSD[269]

  • 不良ブロックの交換に使用されるスペアブロックの状態

（0x01：正常、0x02：警告：ブロック使用率80％、0x03：緊急：ブロック使用率90％）

EOL 移行情報: EXT_CSD[267]

  • ベンダーはEXT_CSD [301:270]に独自のステータスレポートを提供できます（ただし、ここまではすべて0のみを見ました）。

例えば

mmc-utils:
# mmc extcsd read /dev/mmcblk0
:
eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x01
eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x00
eMMC Pre EOL information [EXT_CSD_PRE_EOL_INFO]: 0x01
:

sysfs:
# cat /sys/block/mmcblk0/device/life_time    
0x00 0x01
# cat /sys/block/mmcblk0/device/pre_eol_info 
0x01
  1. ベンダーはmmc汎用コマンドCMD56（mmc-utilsを使用し、mmc gen_cmd 読み取り <デバイス> [arg])

良い説明は下記をご覧ください。

[1]https://www.kingston.com/en/embedded/emmc-embedded-flash 「eMMCライフサイクルの推定、検証、監視」

おすすめ記事