eMMC上のデータ保護について

Technical Support
, ,
1

verdin i.mx8MPlusについて質問です。

eMMC上のデータ保護についてビット化けや、書き込み時の電源断等でのデータ保護、修復について

eMMCのデバイス上で行われているのでしょうか？

またはTorizonOSのドライバ等での行われているのでしょうか？

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Verdin i.MX8M PlusのeMMCデータ保護について

Verdin i.MX8M Plusモジュールは、産業グレードのフラッシュメモリとして最大32GB eMMCを搭載しています(1)。

eMMCデバイスレベルでの保護機能

eMMCデバイス自体には、以下のようなハードウェアレベルでの保護機能が組み込まれています：

  • ウェアレベリング: eMMCコントローラが自動的にデータの書き込みを異なるメモリセルに分散
  • エラー訂正コード (ECC): ビットエラーの検出と修正
  • バッドブロック管理: 不良ブロックの自動検出と代替ブロックへの置き換え

TorizonOSでのデータ保護

Torizon OSは、コンテナ化されたアプリケーション開発を簡素化するLinuxベースのソフトウェアプラットフォームです(2)。TorizonOSレベルでは、以下のような追加的な保護機能があります：

  • ファイルシステムレベルでの整合性チェック
  • アトミックアップデート機能: OSTree技術を使用した安全なシステム更新
  • 読み取り専用ルートファイルシステム: システムファイルの意図しない変更を防止

電源断対策

電源断時のデータ保護については、eMMCデバイス自体のキャッシュ管理機能とTorizonOSのファイルシステム同期機能の組み合わせで対応されています。

より詳細な技術仕様については、Verdin iMX8M Plus V1.1データシート(3)をご参照ください。

具体的なアプリケーションでのデータ保護要件がございましたら、使用されているTorizon OSのバージョンと具体的な用途をお教えいただけますでしょうか？

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

通常時はファイルシステムをリードオンリーとしています。

ファイル書き込み時に、ファイルシステムをRWでリマウントして

ファイルをコピーしてシャットダウンしています。

その後、1回ほどKernelファイルが壊れて起動できなくなったケースがあります。

考えうる要因や対策について教えてください。

4

I’d be glad to help with your kernel corruption issue! To provide the most accurate guidance, could you let me know which OS and version you are using? You can run the tdx-info command to get detailed information about your system configuration. For more details, please see: https://developer.toradex.com/software/development-resources/tdx-info/

Kernelファイル破損の考えうる要因と対策

考えうる要因

1. ファイルシステム整合性の問題

Torizon OSは通常、読み取り専用ルートファイルシステムを使用して安全性を確保しています(1)。手動でのリマウント操作は以下のリスクを伴います：

  • 非同期書き込み処理中の電源断
  • ファイルシステムメタデータの不整合
  • 書き込みキャッシュの未完了

2. OSTreeとの競合

Torizon OSはOSTreeを使用してファイルシステムツリーを管理しています(1)。手動でのファイルシステム変更は：

  • OSTreeの管理下にあるファイルとの競合
  • アトミック更新メカニズムの破綻

3. composefs統合の影響

Torizon OSでは、composefs技術が統合されており、/etcディレクトリが揮発性になっています(2)。これにより：

  • 実行時の変更が再起動時に失われる
  • ファイルシステム保護機能との競合

推奨対策

1. 適切なデータ永続化方法の採用

# /varディレクトリの使用（OSTreeで管理されない永続領域）
/var/application-data/

(2)

2. systemd-tmpfilesの活用

ファイルの初期化と管理には、systemd-tmpfilesサービスを使用することが推奨されています(2)。

3. コンテナベースアプローチ

Torizon OSの設計思想に従い、アプリケーションデータはDockerコンテナ内で管理することを検討してください(1)：

  • ベースOSから分離されたアプリケーション
  • ハードウェア機能への依存の最小化

4. 信頼性向上サービスの活用

Torizon OSには以下の信頼性向上機能が組み込まれています(3)：

  • Dockerデータ整合性チェッカー
  • 自動ロールバック機能
  • 電源断耐性のあるアップデート

具体的な実装推奨事項

  1. データ保存場所の変更: /varディレクトリ配下への移行
  2. 同期処理の強化: syncコマンドの確実な実行
  3. gracefulシャットダウン: systemdサービスとしての実装
  4. TorizonCore Builderの活用: カスタムイメージでの設定固定化

お使いの具体的なOS版数と実装方法をお教えいただければ、より詳細な対策をご提案できます。

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

Torizon OSバージョンは5.5です。

実際のファイル更新はスクリプトファイルを実行する事でおこなっており、

cpコマンドで更新用のファイルを当該箇所にコピーしています。

その後の起動で、カーネルファイルが一部化けた状態となっており、起動できない状態になりました。

6

これは具体的にどのように実装するのでしょうか？

7

@pal_mouri 様、ご回答遅くなり申し訳ございません。

本件につきましては、別コメントにて、ほぼご回答しております： eMMC上のファイルのデータ化け - #3 by alvaro.tx

基本的に、ビットエラーに対する保護は主に eMMC デバイス側で行われています。

Torizon が提供する追加の保護については、Torizon OS の構成および設計（アトミックアップデートなど）に基づくものとなります。

上記リンクに記載されている Torizon OS に関する詳細な説明は、本件にも同様に適用されます。

アルバロ。

8

アルバロ様

ご回答ありがとうございます。

ToradexAIからの回答である

gracefulシャットダウン: systemdサービスとしての実装

についての具体的な内容についてもご教授頂けますでしょうか？

9

@pal_mouri 様

グレースフルシャットダウンとは、突然の電源断ではなく、Linux の標準的なシャットダウン手順（ソフトウェア制御によるシャットダウン）を用いてシステムを停止または再起動することを指します。これにより、各サービスが正しく停止され、ファイルシステムのバッファが確実にフラッシュされます。

ファイルシステムを RW に再マウントしてファイルを書き込んだ後は、まず sync を実行して、未書き込みのデータをすべてストレージに反映させてください。その後、以下のような Linux 標準のコマンドを用いて、グレースフルシャットダウンまたは再起動を行います。

  • shutdown -h now（電源オフ）

  • shutdown -r now（再起動）

  • poweroff

  • reboot

可能であれば、シャットダウン前にファイルシステムをリードオンリー（RO）に再マウントすることも有効です。ただし、ファイルが使用中の場合は再マウントできないことがあり、その場合は再起動が必要になる可能性があります。

Verdin モジュールでは、ハードウェア的にグレースフルシャットダウンをトリガーする方法として、CTRL_PWR_BTN_MICO# 信号を短時間 GND に接続することも可能です。これは電源ボタン押下と同等の動作となり、クリーンなシャットダウンが実行されます。詳細は Verdin Carrier Board Design Guide の Section 3.3.6 を参照してください。

実行されているアップデートスクリプトの詳細は不明ですが、多くの場合、専用の systemd サービスを用意する必要はありません。アップデート処理の最後に sync を実行し、その後に適切なシャットダウンまたは再起動コマンドを呼び出すだけで十分です。