同期 (Unix)

sync はUnixオペレーティング システムの標準システム コールであり、カーネルファイル システムバッファからのすべてのデータ、つまり低レベルI/Oシステム コールを介して書き込みがスケジュールされているデータを不揮発性ストレージにコミットします。stdio などの高レベル I/O 層は、独自の個別のバッファを維持する場合があります。

Cの関数として、呼び出しは通常のsync()ように宣言されます。システム コールは、syncとも呼ばれるコマンド ラインユーティリティ経由でも利用できます。また、 PerlやNode.js (fs モジュール内) などの他の言語の同様の名前の関数経由でも利用できます。void sync(void)<unistd.h>

関連するシステムコールは、指定されたファイル記述子fsync()に関連するバッファリングされたデータのみをコミットします。^{[1] は}、ファイル内のデータに加えられた変更のみを書き出すためにも使用できますが、必ずしもファイルに関連するメタデータを書き出す必要はありません。^[2] fdatasync()

一部のUnixシステムでは、定期的にsync関数を呼び出す一種のフラッシュデーモンまたはアップデートデーモンが実行されます。一部のシステムでは cronデーモンがこれを実行し、Linuxではpdflushデーモンによって処理されていましたが、pdflushデーモンは新しい実装に置き換えられ、最終的に2012年にLinuxカーネルから削除されました。^{[3]ファイルシステムが}アンマウントされるか、読み取り専用で再マウントされるとき、^[4]たとえばシステムのシャットダウン前などに バッファがフラッシュされます。

LibreOfficeなどの一部のアプリケーションも、一定間隔で回復情報を保存するため sync関数を呼び出します。

適切な耐久性を提供するために、データベースは、書き込まれた情報が、電源障害時に失われるメモリベースの書き込みキャッシュに格納されるのではなく、不揮発性ストレージに確実に到達できるように、何らかの形式の同期を使用する必要があります。たとえば、PostgreSQL は、コミットの耐久性を確保するために、^[5]fsync()や[ ⁶fdatasync() ] など、さまざまな同期呼び出しを使用することがあります。残念ながら、一連のレコードを書き込む単一のクライアントの場合、回転するハードドライブは 1 回転につき 1 回しかコミットできず、1 秒あたり数百回のコミットしか実行できません。^[7]そのため、fsync 要件をオフにすると、コミットのパフォーマンスが大幅に向上しますが、クラッシュ後にデータベースが破損する可能性があります。

データベースでは、最近の変更に関する情報を含むトランザクション ログファイル (通常はメイン データ ファイルよりはるかに小さい) も使用されるため、クラッシュが発生した場合でも変更を確実にやり直すことができ、メイン データ ファイルの同期頻度を減らすことができます。

データ損失を避けるために、 の戻り値をfsync()チェックする必要があります。これは、ライブラリまたはカーネルによってバッファリングされる I/O 操作を実行するときに、データが不揮発性ストレージに書き込まれず、メモリページ キャッシュwrite()にのみ書き込まれる可能性があるため、システム コールまたは呼び出しの使用時にエラーが報告されない可能性があるためです。代わりに、書き込みによるエラーは、、または のシステム コール中に報告されることがよくあります。^[8] 2018 年より前は、特定の状況下での Linux の動作により、エラー ステータスが報告されませんでした。^{[9] [10]}動作の変更は、2018 年 4 月 23 日に提案されました。^[11]fflush()fsync()msync()close()fsync()

ハードディスクはデフォルトで、書き込みをバッファリングするために独自の揮発性書き込みキャッシュを使用する場合があります。これにより、パフォーマンスが大幅に向上しますが、書き込みが失われる可能性があります。^[12] hdparm -Fなどのツールは、HDDコントローラにオンドライブ書き込みキャッシュバッファをフラッシュするように指示します。キャッシュをオフにするとパフォーマンスへの影響が非常に大きいため、通常は保守的なFreeBSDコミュニティでさえ、FreeBSD 4.3でデフォルトで書き込みキャッシュを無効にすることを拒否しました。^[13]

SCSIおよびネイティブ コマンド キューイングを備えたSATA (ただし、プレーン ATA ではTCQがあってもそうではない) では、ホストは、データがディスクのプラッタに到達したとき、またはディスクのバッファ (オンボード キャッシュ) に到達したときに完了の通知を受けるかどうかを指定できます。ハードウェア実装が正しいと仮定すると、この機能により、ディスクのオンボード キャッシュを使用しながら、 などのシステム コールの正しいセマンティクスを保証できます。^[14]このハードウェア機能はForce Unit Access (FUA) と呼ばれ、ATA (または SATA 非 NCQ) ディスクで行われるようにキャッシュ全体をフラッシュするよりも少ないオーバーヘッドで一貫性を実現します。^[15] Linux は 2007 年頃に NCQ を有効にしましたが、初期のドライブでサポートされていないことを理由に、2012 年まで SATA/NCQ FUA を有効にしませんでした。^{[16] [17]}fsync

2008年にリリースされたFirefox 3.0では、パフォーマンスを低下させることが判明したシステムコールが導入されました。このコールは、埋め込まれたSQLitefsyncデータベースの整合性を保証するために導入されました。^[18] Linux Foundationの最高技術責任者であるTheodore Ts'oは、「fsyncを恐れる」必要はなく、Firefox 3の速度低下の本当の原因はfsyncの過度の使用であると主張しています。^{[19]しかし、彼は（} Mike Shaverの言葉を引用して） 次のようにも認めています。 fsync

かなり一般的なLinux構成、特にext3ファイルシステムを「data=ordered」モードで使用している場合、fsyncを呼び出すと、呼び出されたファイルのデータだけでなく、そのファイルシステムのすべてのバッファリングされたデータがフラッシュされます。^[20]

• ページキャッシュ
• iノード

• sync(8) - Linux マニュアルページ
• http://austingroupbugs.net/view.php?id=672