eMMC上のファイルのデータ化け

Technical Support
1

Verdin iMX8M Plus Quad 4GB WB IT V1.1Aを弊社製品で使用しております。

Torizon5.5をベースにアプリケーションを搭載しております。

構成として、Docker以降のアプリケーション環境を、システム側とパーティションを分け運用しております。

システム側は、ファイルシステムをリードオンリーとして運用しております。

Docker以降のアプリケーション環境はRW可能な状態です。

アプリケーションの機能としてバージョンアップ機能で、アプリケーション環境及び、システム側のファイルを更新(書き換え)る機能を有しています。

その際に、システム側はリードオンリー状態を解除(RWでリマウント)して、更新します。

このバージョンアップを行う際に、システム側のファイルを更新し、シャットダウンを行いました。シャットダウン後起動を行うと、カーネルロード時にエラーとなりu-bootで再起動が繰り返される症状が発生しました。

カーネルファイルを正常なファイルと比較すると一部データが異なっておりました。

質問の内容ですが

eMMC上のビット化け等のデータ保護、補正について、eMMCのデバイスで行われているのか、eMMCのファイルシステムとしてドライバ側でおこなわれているかどちらでしょうか？

もしくはビット化け等のデータ保護、補正についてはデバイスとも、ドライバ側とも機能的にないのでしょうか？

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.

(1) (2) (3) (4) (5) (6) (7)

eMMCのデータ保護とリードオンリーファイルシステムについて

重要な製品変更通知

お使いのVerdin iMX8M Plus Quad 4GB WB IT V1.1Aは、製品変更通知（PCN）の対象製品です(4)。この製品は在庫が枯渇次第販売終了となり、V1.1Bへの移行が推奨されています(4)。

リードオンリーファイルシステムに関する制限事項

Toradexの基本BSPレイヤーおよびリファレンスイメージは、リードオンリーファイルシステムをサポートしていません(1)。これは、リードオンリーシステムでは動作しない機能があるためです(1)。リード/ライトファイルシステムの機能は、モジュールのホスト名におけるシリアル番号の設定など、システムの複数の部分で使用されています(1)。

eMMCのデータ保護について

提供された情報源では、eMMCデバイス自体またはドライバレベルでのビット化けやデータ保護・補正機能に関する詳細な技術情報は見つかりませんでした。

推奨事項

  1. 製品のアップグレード: V1.1BはTorizon OS 6の6.2.0以降でサポートされています(4)
  2. リードオンリーファイルシステムの実装: 詳細については、How to implement a Read-Only Rootfs (Linux)を参照してください(1)

eMMCのデータ保護機能の詳細については、より具体的な技術情報が必要です。以下の関連リソースをご確認いただくか、一般的な回答をご希望でしたらお知らせください：

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

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

いつもお世話になっております
Toradex Japanのアルバロです。

詳細なご説明をいただきありがとうございます。

eMMC におけるビットエラーに対するデータ保護および訂正についてのご質問ですが、
基本的にはビットエラーの検出および訂正はeMMC デバイス自体で処理されており、Linux のファイルシステムドライバ側で行われるものではありません。

本モジュールに搭載されている 32GB の産業用 eMMC（Kingston など複数ベンダーから調達） には、ECC（Error Correcting Code）を備えた内部コントローラ が実装されています。
この ECC は eMMC デバイス内部で動作し、下層のフラッシュメモリを透過的に保護します。
内部で訂正できないエラーが発生した場合は、eMMC からホストシステムへ読み書きエラーとして通知されます。

Linux 側の動作としては、
・MMC ドライバおよびファイルシステム（ext4 など）は、ビットレベルでのエラー訂正は行いません。
・ext4 はジャーナリングやチェックサムによりファイルシステムのメタデータ破損は検出できますが、
カーネルイメージのような通常のファイルデータ自体を保護する仕組みはありません。
・そのため、ファイルシステムはブロックデバイスから正しいデータが返ってくることを前提としています。

ご説明いただいた状況から判断すると、
バージョンアップ後に発生したカーネル破損は、eMMC のランダムなビットエラーが原因である可能性は低い と考えられます。
特に産業用 eMMC において、ECC をすり抜けるランダムなビットエラーは非常に稀です。

一方で、以下のような アップデート手順に起因するリスク は一般的に考えられます。
・システムパーティションを RW で再マウントし、ブートに関わるファイルを直接書き換えている
・書き込みバッファのフラッシュやファイルシステムのコミットが完了する前に電源断やリセットが発生している
・アトミックな更新やロールバック機構が存在しない

カーネルやブート関連ファイルが上書き中に中断された場合、
ファイルが不完全な状態で保存され、U-Boot でのカーネルロードに失敗し、再起動を繰り返す事象につながる可能性があります。

参考として、Torizon ではブートに関わるシステムファイルを直接書き換える方式は採用していません。
Torizon ではOSTree ベースのアトミックアップデート機構を使用しており、
・新しいシステムイメージとして更新を保存
・更新完了後にのみ新バージョンへ切り替え
・起動失敗時には自動的にロールバック可能

といった仕組みにより、電源断や更新中断による破損リスクを大幅に低減しています。

外部のアップデートツールをご使用の場合は、
・アトミック更新または A/B 構成になっているか
・再起動前に十分な同期および検証が行われているか
・障害時にロールバックできる仕組みがあるか

といった点をご確認いただくことをお勧めいたします。

本回答が、データ保護の仕組みおよび今回の事象の切り分けにお役立ていただければ幸いです。

以上、引き続きよろしくお願いいたします。
アルバロ。

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