Linux システムが変更をディスクにすぐに同期するように設定されているかどうかを確認するにはどうすればよいですか?

Linux システムが変更をディスクにすぐに同期するように設定されているかどうかを確認するにはどうすればよいですか?

私のシステムのインデックスエンジンが思い出す動作中は大量のディスクを使用し、Firefox アドオンの設定を変更するたびにディスクアクティビティが発生していました。これらのアプリケーションが変更をすぐにディスクに同期するように設計されているのか、それともシステム構成の設定によるものなのかはわかりません。

調べる方法はあるでしょうか。

追伸:私は質問を残しましたソフトウェアの推奨事項recoll/xapian の問題について。

答え1

の出力にファイルシステムが表示されるかどうかを確認しますgrep -w sync /proc/mounts。ネタバレ: 答えは「いいえ」です。即時同期でファイルシステムをマウントすると、非常に遅くなります。(また、小さな書き込みが多数発生するため、フラッシュ デバイスの寿命が短くなります。)

一部のアプリケーションでは、fdatasync残念ながら、Unix API は復元力に関して適切に設計されていません¹。アプリケーションの観点からは、一部の変更は復元力が必要です。アプリケーションがリモート マシンに変更が保存されたことを示すデータを送信しているためです。この場合はfdatasync正しいインターフェイスです。しかし、多くのアプリケーションでは、異なるもの、つまり、変更 1 の後に変更 2 を行い、システムが途中でクラッシュした場合、再起動後に変更 1 なしで変更 2 が行われないことが保証される必要があります。(例: 変更 1 = ファイルの新規バージョンの書き込み、変更 2 = 古いバージョンの削除)。ファイルシステムは、パフォーマンスのためにファイルシステムの書き込み順序を変更します。通常、これはアプリケーションには見えません。これは、ファイルシステムのキャッシュ/バッファとディスクの間で何が起こるかだけに関するものであり、アプリケーションに見えるものに関するものではないためです。しかし、システム クラッシュの場合、ディスクの内容は実際のディスク書き込みの順序を反映します。 「この変更は、あの変更の前に行う必要がある」という API がないため、アプリケーションは、fdatasync貧乏人のフォールバックとして使用します (変更 1 を実行し、呼び出してfdatasyncディスクに伝播されたことを確認してから、変更 2 を実行します)。これは、特にフラッシュなどの書き込み速度が遅いメディアでは、パフォーマンスに悪影響を及ぼす可能性があります。

fdatasyncまたはその類似のの過度の使用により、アプリケーションがシステム上で極端に遅くなる場合はfsync食べるデータfsync/呼び出しを無効にしますfdatasync。ただし、システムが途中でクラッシュした場合、不整合なデータが残る可能性があることに注意してください。

私の回答がrecollに関係しているのか、Firefoxアドオンの設定変更に関係しているのかはわかりません。これらの操作はおそらく読むディスクから。特に recoll の役割は大量のデータを読み取ることです。

また、変更がすぐにディスクに同期されない場合でも、一部のデータは書き込まれることが予想されます。データがディスクに書き込まれない場合、そのデータはメモリ内に残る必要があり、その間、そのメモリを他のより有用な用途に使用することはできません。さらに、ディスクをビジー状態に保たないのは無駄です。書き込むデータがある場合、カーネルは書き込みを開始し、その間、アプリケーションは実行を継続してさらにデータを生成します。

¹ファイルシステム設計における復元力とは、システムがクラッシュした場合にファイルシステムへの変更が保持されるかどうかという問題です。

関連情報