組み込み環境で同期するかどうか？

Question

フラッシュのチャンクでDebian10を実行するシングルボードアプライアンスがあります。 UBIFSが使用され、rorootsとrw/varの2つのボリュームに分割されます。電源の入れ直し/リセットの条件下では、0バイトのファイルになってしまう可能性があることがわかりました。 「設定」は/ var/opt/myAppに保持します。/varのマウントオプションを変更してsyncを含めると、これらのインシデントがなくなるようです。

私は通常のアドバイスが同期よりも非同期が好まれるということを知っていますが、例外が何であるかについての説明がほとんどなく、通常は「通常、しかし常にではありません」で洞窟に入れられます。

別の解決策は、データをディスクに書き込むすべての呼び出しサイトを変更して、ファイルを閉じるときにフラッシュするだけでなく、同期することです（私はPythonで多くのことを行います）。コーディング/完全性のために、syncとしてマウントすることは、作業が少ないように見え、場所に同期ガードを追加することを見逃さないようにしました。

さらに、アプライアンスがUSBサムドライブにデータを保存できるようにします。データが書き込まれた直後にヤンクアウトされたときの損失を減らすために、これらの同期もマウントする必要があると思います。

これは、syncの使用を正当化するのに適した例外的な構成ですか？または、別のソリューションを使用する必要がありますか？

Answer 1

これが私の意見です：事前に冗長性をお詫びします。

特にubifsについて話しているときは、常にsync /同様のオプションのいずれかを使用する必要があります。

ubifsはwrite-back cachingをサポートします

つまり、ファイルに書き込まれた変更は直接フラッシュされません。それらは最初にページキャッシュに保存され、後でフラッシュに書き込まれます。 （UBIFSのNANDフラッシュのwrite buffersの詳細を読む）

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

これはfsのasynchronous動作であることに注意してください。

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

Ubifsのようなasynchronousファイルシステムを使用している場合、書き込みがフラッシュに書き込まれるようにする責任はアプリケーション開発者にあります。 write（2）のmanページの内容は次のとおりです。

$ 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-fs全体を同期します。最適ではないかもしれません

fsync-主に仕事をします

fdatasync-メタデータ（権限）ではなく、データの変更のみがフラッシュされます。 fsyncよりも最適かもしれません（わからない）

また読む fsyncについてよく読む

したがって、最後に、あなたのオプション：

1. 'sync'でマウント-パフォーマンスヒットあり
2. 上記のsyncオプションを使用してアプリケーションを改善します。
3. アプリケーションで0バイトのファイルを処理する
4. 一時ファイルを作成し、後で名前を変更する

最後に考えたのは、jffs2のような同期fsに切り替えたいかもしれません（ただし、NANDフラッシュを使用している場合は完全に同期していません）。私はこれがあなたの質問への答えではないことを知っていますが、ええと、これを書いた方がいいかもしれません。