Armadilloフォーラム

ファイルシステム破たん対策について

eriko0305

2017年8月24日 20時05分

お世話になっております。

Armadillo-IoT G3Lにて、量産品の製造を検討しております。

下記フォーラムへの投稿にて、ファイルシステムが破たんするリスク回避としてoverlayfsの利用を案内していただき、
overlayfsを利用することに決めました。
しかし、弊社開発中のアプリケーションの仕様上、電源断した後も起動中に取得した情報(アプリケーションログ)を保持する必要があり
ROMにデータを書き込む必要があると考えております。
そこで以下の方法を取ることは有効な手段となりますか?
また、このようなことが可能でしょうか?

検討している方法:
・ルートファイルシステムが動作するパーティションと電源断後も情報を保持するためのパーティションを作成する。
  # パーティションを2つ作成し、ルートファイルシステムが動作している領域には、書き込みを行いません

制約:
・SDカードやUSBメモリ等の別ストレージの追加は行いたくありません。

ファイルシステム破損について問い合わせていただいたフォーラム:
https://armadillo.atmark-techno.com/forum/armadillo/2719

以上、よろしくお願いいたします。

コメント

at_takumi.ando

2017年8月25日 11時48分

安藤です。

>そこで以下の方法を取ることは有効な手段となりますか?
>また、このようなことが可能でしょうか?

>・ルートファイルシステムが動作するパーティションと電源断後も情報を保持するためのパーティションを作成する。
>  # パーティションを2つ作成し、ルートファイルシステムが動作している領域には、書き込みを行いません

可能です。
この方法をとった場合、ルートファイルシステムの破損を回避することは出来ます。
しかし、新しく作成した "情報を保持するためのパーティション" 上のデータの破損は発生する可能性があります。

予期しない電源断を考慮する限り、eMMC上に書き込むデータが破損する可能性はあります。

saitoh

2017年8月25日 12時39分

齊藤と申します
そもそも予期しない電源断が起きなくするのはコスト的に無理なんでしょうか?
電気二重層コンデンサとDCDCコンバーターを入れて電源断後1分くらい稼働できるようにしておけば、電源喪失割り込み(これもGPIOでつくれる)から穏便にシャットダウン(SDカードなどのアンマウントまでやるのが更に安全)できると思いますが。
あとrcスクリプトを修正して起動時にfsckする(念のため)。

eriko0305

2017年8月25日 13時15分

安藤さま>
ご連絡、ありがとうございます。
検討した内容で、ルートファイルシステムの破綻は回避できることがわかり良かったです。
eMMCに書き込みを行うパーティション上のデータ破損について承知しました。
お手数をお掛けし大変申し訳ないのですが、上記を行う参考情報がありましたら教えていただけないでしょうか?

齊藤>
ご連絡、ありがとうございます。
>そもそも予期しない電源断が起きなくするのはコスト的に無理なんでしょうか?
ユースケースを考慮すると難しいです。
電気二重層コンデンサとDCDCコンバーターの追加についても、コスト的に難しい状況です。
アドバイスいただきありがとうございます。上記で検討している方法で対応しようと思います。

以上、よろしくお願いいたします。

at_takumi.ando

2017年8月25日 15時36分

安藤です。

>お手数をお掛けし大変申し訳ないのですが、上記を行う参考情報がありましたら教えていただけないでしょうか?

eMMCのパーティション変更の方法についてでしょうか?

現在リリースしているインストールディスクでは、fdiskコマンドで以下のパーティション構成でフォーマットしています。

Device         Boot  Start     End Sectors   Size Id Type
/dev/mmcblk2p1          16   62591   62576  30.6M  b W95 FAT32 // Linuxカーネル、DTB
/dev/mmcblk2p2      312640 7471103 7158464   3.4G 83 Linux     // ユーザーランド
/dev/mmcblk2p3       62592  312639  250048 122.1M  b W95 FAT32 // node-eye

インストールディスクで、fdiskでeMMCをフォーマットしているのは
/images/install.sh 内のemmc_format()関数です。
fdiskに与えるパラメータを変更することで、パーティションの数とサイズを変更することができます。

但し、弊社で提供している標準のアプリケーションが動作しなくなる可能性があります。
(例えば、node-eyeでは第3パーティションを使用しているため)
必要に応じてパーティション構成を検討してください。

fdiskコマンドの使い方については、manページ等を参考にするのが良いかと思います。

$ man fdisk

forks_yas

2017年8月25日 15時40分

寺島と申します。

最近のフラッシュメディアはウェアレベリングによって使用中の領域も適宜詰め替えをするので、書込み中の予期せぬ電源断の場合、
パーティションを別けていても同一デバイスの場合は書き込み中のデータだけでなく、書込みを行わないシステム用パーティション
のデータが破損する可能性を否定できないと思います。
不意の電源断によってシステムの破損が絶対に許されない場合は、データ用とシステム用のデバイスは分離すべきです。

> 検討している方法:
> ・ルートファイルシステムが動作するパーティションと電源断後も情報を保持するためのパーティションを作成する。
>   # パーティションを2つ作成し、ルートファイルシステムが動作している領域には、書き込みを行いません
>
> 制約:
> ・SDカードやUSBメモリ等の別ストレージの追加は行いたくありません。

eriko0305

2017年8月25日 16時48分

安藤様>
早々のご回答ありがとうございます。
第3パーティションを情報保持用に使うということですね。
当方では、node-eyeのサービスは利用しない予定ですので、問題ないと思いました。
教えていただいた方法を試してみたいと思います。ありがとうございました。

寺島様>
ご回答ありがとうございます。
パーティションを分けた場合もリスクは残るのですね。
別パーティションにした場合と、そうでない場合でファイルシステム破たんリスクがどれくらい変わるのかご存知ですか?
お手数をお掛けし、申し訳ありません。

以上、よろしくお願いいたします。

at_takumi.ando

2017年8月25日 17時36分

安藤です。

> 第3パーティションを情報保持用に使うということですね。

そういった使い方も考えられます。
サイズが足りなければパーティションサイズを変更する必要もありますし、
ファイルシステムも必要に応じて変更してください。
単にパーティションの数を増やすことも考えられます。

> 別パーティションにした場合と、そうでない場合でファイルシステム破たんリスクがどれくらい変わるのかご存知ですか?

開発中のアプリケーションが、どれくらいの頻度で、どれくらいのサイズのログを書き込むのかに依存します。
寺島さんの仰るとおり、ウェアレベリングによって書込みを行わないシステム用パーティションのデータが
破損する可能性はあるかと思います。

少なくとも、overlayfsを使用すればルートファイルシステムに対する書き込みは行われなくなるので、
ファイルシステムが破損するリスクは、アプリケーションがログ用のパーティションに対して書き込む頻度に依存します。

eriko0305

2017年8月28日 15時16分

安藤様

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

Armadillo-IoT G3LのROM領域が4Gであることから、アットマークテクノ様からリリースされているインストールディスクですと、あと400Mほど第3パーティションに割り振ることが可能だと考えておりますが、認識は合っていますでしょうか?
第1, 第2パーティションは、Linuxカーネル、DTBやユーザーランドの領域であり、サイズを少なくして第3パーティションを増やすようなことは行わない方が良いと思いました。

>> 別パーティションにした場合と、そうでない場合でファイルシステム破たんリスクがどれくらい変わるのかご存知ですか?
>開発中のアプリケーションが、どれくらいの頻度で、どれくらいのサイズのログを書き込むのかに依存します。
コメントありがとうございます。
アプリケーションがログを書き込む頻度は同じとして、別パーティションと同じパーティションに書き込む場合では、ルートファイルシステム破たんリスクは、
別パーティションに書き込んだ場合の方が少なくなると思ったのですが、認識は合っていますか?
どちらの場合もリスクがあることは分かったのですが、問題の発生率が変わるのかと思いました。

お手数をお掛けします。

以上、よろしくお願いいたします。

at_takumi.ando

2017年8月28日 16時03分

安藤です。

> Armadillo-IoT G3LのROM領域が4Gであることから、アットマークテクノ様からリリースされているインストールディスクですと、あと400Mほど第3パーティションに割り振ることが可能だと考えておりますが、認識は合っていますでしょうか?

製品マニュアルにも記載しておりますが、Armadillo-IoT G3Lに搭載されているeMMCの容量は、約 3.8GB(約 3.6GiB)です。

Armadillo-IoT G3L 製品マニュアル 3.3. 仕様
https://manual.atmark-techno.com/armadillo-iot-g3l/armadillo-iotg-g3l_p…

fdiskコマンドで確認していただければ分かると思いますが、eMMCの領域はフルに使用しております。

root@armadillo:~# fdisk -l /dev/mmcblk2
 
Disk /dev/mmcblk1: 3.6 GiB, 3825205248 bytes, 7471104 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
 
Device         Boot  Start     End Sectors   Size Id Type
/dev/mmcblk1p1          16   62591   62576  30.6M  b W95 FAT32
/dev/mmcblk1p2      312640 7471103 7158464   3.4G 83 Linux
/dev/mmcblk1p3       62592  312639  250048 122.1M  b W95 FAT32
 
Partition table entries are not in disk order.

> 第1, 第2パーティションは、Linuxカーネル、DTBやユーザーランドの領域であり、サイズを少なくして第3パーティションを増やすようなことは行わない方が良いと思いました。

例えば、仮に必用なアプリケーション等をインストールした状態で、eMMCの第2パーティション(ユーザーランド領域)の空き容量を
確認すれば、第2パーティションのサイズをどれだけ削減できるか分かるかと思います。
必要に応じて、適宜パーティションサイズを変更してください。

root@armadillo:~# df /dev/mmcblk2p2
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/mmcblk2p2   3457408 1099028   2163036  34% /

> アプリケーションがログを書き込む頻度は同じとして、別パーティションと同じパーティションに書き込む場合では、ルートファイルシステム破たんリスクは、
> 別パーティションに書き込んだ場合の方が少なくなると思ったのですが、認識は合っていますか?
> どちらの場合もリスクがあることは分かったのですが、問題の発生率が変わるのかと思いました。

おそらく、別パーティションにログを書き込んだ場合の方が、ルートファイルシステム(overlayfs有効)が破損する確率は低いかと思います。
ただし、ウェアレベリングの方式については、eMMC内蔵のコントーローラーの仕様に依存します。
Armadillo-IoT G3Lに搭載されているeMMCのコントーローラー仕様は非公開のため、ルートファイルシステム破損の発生率が
どの程度変化するかは分かりません。

at_takumi.ando

2017年8月28日 16時06分

ごめんなさい、fdiskコマンドの実行結果を貼り間違えていました。
正しくは以下の通りです。(eMMCは/dev/mmcblk2)

root@armadillo:~# fdisk -l /dev/mmcblk2
 
Disk /dev/mmcblk2: 3.6 GiB, 3825205248 bytes, 7471104 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
 
Device         Boot  Start     End Sectors   Size Id Type
/dev/mmcblk2p1          16   62591   62576  30.6M  b W95 FAT32
/dev/mmcblk2p2      312640 7471103 7158464   3.4G 83 Linux
/dev/mmcblk2p3       62592  312639  250048 122.1M  b W95 FAT32
 
Partition table entries are not in disk order.

eriko0305

2017年8月28日 19時40分

安藤様

回答、ありがとうございます。
教えていただいた方法で、第3パーティションのサイズを変更することが出来ました。
第3パーティションをマウントすることで、ルートファイルシステムからファイルの書き込みができることを確認しました。

>おそらく、別パーティションにログを書き込んだ場合の方が、ルートファイルシステム(overlayfs有効)が破損する確率は低いかと思います。
ありがとうございます。承知いたしました。

丁寧に回答していただきありがとうございました。

以上、今後ともよろしくお願いいたします。