☰

組み込み環境で同期または同期しない場合は？

tag-icon • tag-icon linux filesystems embedded synchronization async
組み込み環境で同期または同期しない場合は？

フラッシュメモリにDebian 10を実行する単一のボードデバイスがあります。 UBIFSを使用して、2つのボリューム（roルート1つとrw / var1つ）に分割します。電源を入れ直したりリセットしたりすると、0バイトのファイルが生成されることがわかりました。私の「設定」を/var/opt/myAppに保存します。 /varのマウントオプションを含めるように変更すると、syncこれらのイベントが消えるようです。

私は非同期が同期より優れているという一般的なアドバイスを知っていますが、一般的に可能な例外の説明はほとんどなく、「通常ですが常にそうではありません」と注意してください。

もう1つの解決策は、ファイルが閉じられたときにフラッシュするだけでなく、同期するためにディスクにデータを書き込むすべての呼び出しサイトを変更することです（私はPythonを使ってこれをたくさん行います）。コーディング/完全性の観点から、インストールはsync作業量を減らし、普遍的なので、どこかに同期保護を追加することを見逃さないようにするようです。

また、デバイスがUSBサムドライブにデータを保存できるようにします。データが作成されるとすぐに、データを取り出すときに損失を減らすために、これらの同期もインストールする必要があると思います。

これが使用を正当化するのに適した特別な構成ですかsync？それとも代替ソリューションを使用する必要がありますか？

答え1

私のポイントは次のとおりです。あらかじめ冗長に話してすみません。

具体的に話すとき、ubifs私たちは常にsyncこれらの/類似のオプションの1つを選ぶべきです。

ubifsサポートするwrite-back caching

これは、ファイルに書き込まれた変更がフラッシュメモリに直接書き込まれないことを意味します。まず、ページキャッシュに格納され、次にフラッシュメモリに書き込まれる。 （write buffersUBIBSのNANDフラッシュの詳細）

これにより、書き込み回数が減り、ファイルシステムのパフォーマンスが向上します。

これはasynchronousfsの振る舞いです。

質問で述べたように、-syncオプションを使用してUBIFSをマウントすると、ファイルシステムが作成されますがsynchronous（毎回変更をフラッシュに書き込む）パフォーマンスが低下します。

ubifsなどのファイルシステムを使用している場合、書き込みをasynchronousフラッシュメモリに書き込む責任はアプリケーション開発者にあります。 write(2) のマニュアルページは次のとおりです。

$ man 2 write
NOTES
   A  successful return from write() does not make any guarantee that data
   has been committed to disk.  In fact, on some buggy implementations, it
   does  not  even guarantee that space has successfully been reserved for
   the data.  The only way to be sure is to call fsync(2)  after  you  are
   done writing all your data.

使用

sync- ファイルシステム全体を同期します。最適ではないかもしれません

fsync-主に作業を完了します。

fdatasync- メタデータ（権限）ではなくデータの変更のみが更新されます。可能以上に最適化fsync（不明）

また読んでくださいfsyncに関する良い記事

結局のところ、あなたの選択は次のようになります。

  1. 「同期」マウントの使用 - パフォーマンスの低下
  2. 上記のオプションを使用してアプリケーションを改善しますsync。
  3. アプリケーションはゼロバイトファイルを処理します。
  4. 一時ファイルを作成し、後で名前を変更します。

jffs2最後に、同期ファイルシステム（NANDフラッシュを使用している場合は完全同期ではない）に切り替えたい場合があります。これはあなたの質問に対する答えではないことがわかりますが、ええと、こう書くのが良いと思います...

関連情報