Armadilloフォーラム

/etc/atmark/containers/のファイルについて

kn_kobayashi

2023年1月13日 21時11分

お世話になっております。
無知で申し訳ありませんが、Armadillo-IoTG4の2面化やbtrfsに関するポリシーについて確認させてください。

「/etc/atmark/containers/」の下にコンテナ作成用のファイル(以後、confと記載します)を配置すると思いますが、
このファイルを更新時に電源断から保護する機構(btrfsの使用等)はございませんよね。
なので、confを手で編集後、eMMCに書き込もうと「persist_flle」を実行するタイミングで
もし運悪く電源断が発生したら、confは破損する可能性があるということですよね。

一方、コンテナの実体「/var/lib/containers/storage_readonly」等は
パーティションに配置し、書込み時の電源断から保護する様にされていると思います。

confの方も破損すればコンテナが起動できなくなるので、システムとしては致命的であり、
confも「/var/lib/containers/storage_readonly」に置くべきでは?なぜ分けているの?
と疑問に思いました。

上記について、思想、ポリシー、理由などがあると思っていますので、
そのあたりをご教授いただけないでしょうか。

小生が勝手に想像したものとしては以下の様な理由でした。
・confファイルはサイズ的にもものすごい小さく、またファイルシステム自体が破損するわけではないので、
 万が一、破損しても、また外からファイルを持ってきてコピーすればすぐに復旧できるため。
・また、このファイルを書き換えることなど運用開始後はそもそもほとんどありえない。
 また、ファイルサイズが小さい故に書込みも一瞬で終わる為、たまたま書き換えようとした
 その瞬間に電源断が起きる可能性など天文学的なものであり、考慮する必要がない。
・ただ、もしそれすらも許容できない心配性なユーザーであれば、
 podman_start -c を使用し、btrfs上に置いているファイルを使えばいい、という判断。

コメント

> お世話になっております。
> 無知で申し訳ありませんが、Armadillo-IoTG4の2面化やbtrfsに関するポリシーについて確認させてください。
>
> 「/etc/atmark/containers/」の下にコンテナ作成用のファイル(以後、confと記載します)を配置すると思いますが、
> このファイルを更新時に電源断から保護する機構(btrfsの使用等)はございませんよね。

/etc等はパーティションが2面かつそもそもreadonlyでマウントされ、overlayfsによって
書き込みはramに退避されます。その場合は当然電源断しても元の状態に復帰します。

手動でpersist_fileコマンドを使う場合はoverlayfsを貫通して書き込みますが、通常運用時は
swuで書き込まれることを想定しています。

swuから書き込む場合は、本領域は2面のパーティションで構成されており、中途状態をram上、
完結後ウラ面への書き込み、ウラ面の書き込み完了が確定して次回起動でパーティションを交代
という仕様となっているため、中途状態での電源断での破壊を回避しています。

> なので、confを手で編集後、eMMCに書き込もうと「persist_flle」を実行するタイミングで
> もし運悪く電源断が発生したら、confは破損する可能性があるということですよね。

はい。上記のとおり運用時はswu経由でのアップデートを実施してください。

ご回答ありがとうございます。
すみません、最後に1点だけ教えてください。

> /etc等はパーティションが2面かつそもそもreadonlyでマウントされ、overlayfsによって
> 書き込みはramに退避されます。その場合は当然電源断しても元の状態に復帰します。

どこを見れば、「/etc等のパーティションが2面化されている」のを判別できますでしょうか。
dfやlsblkを実行すれば「/dev/mmcblk2p5」が「/var/lib/containers/storage_readonly」等に
マウントされ、btrfsで書き換えしていることなどは目視で理解できますが、「/etc」等は
表示されず、どのように確認すればいいのか分からず、困っています。
また、何かの資料に記載がありましたら、そちらを教えていただきたいです。

よろしくお願いいたします。

> どこを見れば、「/etc等のパーティションが2面化されている」のを判別できますでしょうか。
> dfやlsblkを実行すれば「/dev/mmcblk2p5」が「/var/lib/containers/storage_readonly」等に
> マウントされ、btrfsで書き換えしていることなどは目視で理解できますが、「/etc」等は
> 表示されず、どのように確認すればいいのか分からず、困っています。
> また、何かの資料に記載がありましたら、そちらを教えていただきたいです。

現在の/が何であるかはu-bootが決定してカーネル起動パラメーターのrootに
デバイス名を渡しているのでdfには出ません。mountコマンドを使う以前の
カーネル内部の挙動です。

カーネルの起動パラメーターのrootはカーネル起動以前に与えるため、
ブートローダーであるu-bootによって渡されます。

u-bootのコンソールでprintenvを実行すると bootargsにroot=${mmcroot}が
セットされておりmmcrootにはmmcblk2p1か2p2が指定されていることがわかるはずです。

例: mmcblk2p2がroot (/) になる。オプションがroなので、readonlyでマウント

mmcroot=/dev/mmcblk2p2 rootwait ro

このu-bootのmmcroot変数へのデバイス指定の変更は前述のswuによる
アップデートの後半、裏面への書き込みの確定後に起動中のユーザーランドから
u-bootの変数領域を変更することで実施しています。
(u-boot自体も2面化されているので、裏面側のu-bootの変数領域に書いてます。)

当然ですが2面化している内、その時点で起動に使って居ない側は、
swuのアップデートの処理中以外マウントもされていないので起動時は見えません。

起動に使っていない側のパーティションを観察するには
abos-ctrl mount-old コマンドを使うと/targetにマウントすることができ、
内容を確認できます。

ご回答ありがとうございます。
なるほど。。理解できました。
ご丁寧に説明いただき、ありがとうございました。