耐久性のあるデータ ストレージと Linux ファイル API

クラウド システムでのデータ ストレージの安定性を研究している私は、基本的なことを理解していることを確認するために、自分自身でテストすることにしました。 私 NVMe仕様を読むことから始めました データの永続性に関する保証 (つまり、システム障害後にデータが利用可能であることの保証) が NMVe ディスクに与えられることを理解するために。 私は次のような主な結論を出しました。データ書き込みコマンドが与えられた瞬間から、記憶媒体に書き込まれる瞬間までのデータの損傷を考慮する必要があります。 ただし、ほとんどのプログラムでは、システム コールはデータの書き込みに非常に安全に使用されます。

この記事では、Linux ファイル API によって提供される永続化メカニズムについて説明します。 ここではすべてが単純である必要があるようです。プログラムはコマンドを呼び出します。 write()、このコマンドの操作が完了すると、データはディスクに安全に保存されます。 しかし write() アプリケーション データを RAM にあるカーネル キャッシュにコピーするだけです。 システムにデータをディスクに強制的に書き込むには、いくつかの追加メカニズムを使用する必要があります。

一般に、この資料は、私が興味のあるトピックについて学んだことに関する一連のメモです。 最も重要なことについて簡単に説明すると、持続可能なデータ ストレージを整理するには、次のコマンドを使用する必要があることがわかります。 fdatasync() またはフラグを付けてファイルを開く O_DSYNC。 コードからディスクに転送される途中でデータに何が起こるかについて詳しく知りたい場合は、以下を参照してください。 この 記事。

write() 関数の使用の特徴

システムコール write() 標準で定義されている IEEE POSIX ファイル記述子にデータを書き込もうとする試みとして。 作業が無事に完了したら write() データ読み取り操作は、データが他のプロセスまたはスレッドからアクセスされている場合でも、以前に書き込まれたバイトを正確に返す必要があります (ここで POSIX 標準の対応するセクション)。 それは、通常のファイル操作とスレッドの相互作用に関するセクションには、XNUMX つのスレッドがそれぞれこれらの関数を呼び出す場合、各呼び出しは、他の呼び出しの実行がもたらす指示された結果をすべて参照する必要がある、またはまったく影響がありません。 これにより、すべてのファイル I/O 操作は、作業中のリソースに対してロックを保持する必要があるという結論に達します。

これは、操作を意味しますか? write() アトミックですか？ 技術的な観点から言えば、そうです。 データ読み取り操作では、書き込まれた内容をすべて返すか、まったく返さない必要があります。 write()。 しかし、操作は write()、標準に従って、書き留めるように求められたすべてを書き留めて終了する必要はありません。 データの一部のみを書き込むことができます。 たとえば、同じファイル記述子で記述されたファイルに 1024 バイトをそれぞれ追加する XNUMX つのストリームがあるとします。 標準の観点から見ると、各書き込み操作でファイルに XNUMX バイトだけ追加できる場合、結果は許容範囲内になります。 これらの操作はアトミックなままですが、完了後、ファイルに書き込まれるデータは乱雑になります。 ここで このトピックに関する Stack Overflow での非常に興味深い議論。

fsync() および fdatasync() 関数

データをディスクにフラッシュする最も簡単な方法は、関数を呼び出すことです。 fsync（）。 この関数は、変更されたすべてのブロックをキャッシュからディスクに移動するようにオペレーティング システムに要求します。 これには、ファイルのすべてのメタデータ (アクセス時間、ファイル変更時間など) が含まれます。 このメタデータが必要になることはほとんどないと思うので、重要ではないことがわかっている場合は、次の関数を使用できます。 fdatasync()。 で ヘルプ 上の fdatasync() この機能の動作中に、このような量のメタデータがディスクに保存され、これは「次のデータ読み取り操作を正しく実行するために必要」であると記載されています。 そして、これはまさにほとんどのアプリケーションが気にしていることです。

ここで発生する可能性のある問題の XNUMX つは、これらのメカニズムでは、障害が発生した後にファイルが見つかることが保証されていないことです。 特に、新しいファイルが作成されるときは、次のように呼び出す必要があります。 fsync() それが含まれるディレクトリの場合。 そうしないと、クラッシュ後にこのファイルが存在しないことが判明する可能性があります。 その理由は、UNIX ではハード リンクが使用されているため、ファイルが複数のディレクトリに存在する可能性があるためです。 そのため、電話をかける際には、 fsync() どのディレクトリ データもディスクにフラッシュする必要があるかをファイルが知る方法はありません (ここで 詳細についてはこちらをご覧ください)。 ext4 ファイルシステムには次のような機能があるようです。 自動的に 適用する fsync() 対応するファイルを含むディレクトリにコピーされますが、これは他のファイル システムには当てはまらない場合があります。

このメカニズムは、ファイル システムごとに異なる方法で実装できます。 私が使用した ブロックトレース ext4 および XFS ファイル システムで使用されるディスク操作について学習します。 どちらも、ファイルの内容とファイル システム ジャーナルの両方に対して通常の書き込みコマンドをディスクに発行し、キャッシュをフラッシュして、ジャーナルへの FUA (強制ユニット アクセス、データを直接ディスクに書き込み、キャッシュをバイパスする) 書き込みを実行して終了します。 おそらく取引の事実を確認するためにそうしたのでしょう。 FUA をサポートしていないドライブでは、これにより XNUMX 回のキャッシュ フラッシュが発生します。 私の実験によると、 fdatasync() もう少し速く fsync()。 ユーティリティ blktrace ことを示します fdatasync() 通常、ディスクに書き込むデータは少なくなります (ext4 の場合) fsync() 20 KiB を書き込み、 fdatasync() - 16 KiB)。 また、XFS は ext4 よりも若干速いことがわかりました。 そしてここで助けを借りて blktrace それを知ることができました fdatasync() ディスクにフラッシュされるデータが少なくなります (XFS で 4 KiB)。

fsync() 使用時のあいまいな状況

これに関して、あいまいな状況が XNUMX つ考えられます。 fsync()私が実際に遭遇したこと。

最初のこのような事件は 2008 年に発生しました。 当時、Firefox 3 のインターフェイスは、大量のファイルがディスクに書き込まれると「フリーズ」していました。 問題は、インターフェイスの実装がその状態に関する情報を保存するために SQLite データベースを使用していることでした。 インターフェイスで変更が発生するたびに、関数が呼び出されます。 fsync()、安定したデータストレージが十分に保証されました。 当時使用されていた ext3 ファイル システムでは、関数 fsync() 対応するファイルに関連するページだけでなく、システム内のすべての「ダーティ」ページがディスクにフラッシュされます。 つまり、Firefox でボタンをクリックすると、数メガバイトのデータが磁気ディスクに書き込まれる可能性があり、これには何秒もかかる可能性がありました。 私が理解した限りの問題の解決策 この 重要なのは、データベースでの作業を非同期バックグラウンド タスクに移行することでした。 これは、Firefox が実際に必要な以上に厳しいストレージ永続性要件を実装していたことを意味し、ext3 ファイルシステム機能はこの問題を悪化させるだけでした。

2009 番目の問題は 4 年に発生しました。 その後、システム クラッシュの後、新しい ext3 ファイル システムのユーザーは、新しく作成されたファイルの多くが長さ 3 であることに気づきましたが、古い extXNUMX ファイル システムではこのようなことは起こりませんでした。 前の段落では、extXNUMX がディスク上に大量のデータをダンプしすぎて、処理速度が大幅に低下したことについて説明しました。 fsync()。 この状況を改善するために、ext4 は特定のファイルに関連する「ダーティ」ページのみをフラッシュします。 また、他のファイルのデータは、ext3 よりもはるかに長い時間メモリ内に残ります。 これはパフォーマンスを向上させるために行われました (デフォルトでは、データは 30 秒間この状態に留まります。これは次を使用して構成できます) Dirty_expire_centisecs; ここで 詳細についてはこちらをご覧ください)。 これは、クラッシュ後に大量のデータが回復不能に失われる可能性があることを意味します。 この問題の解決策は次のとおりです。 fsync() 安定したデータ ストレージを提供し、障害の影響から可能な限りデータを保護する必要があるアプリケーションで使用されます。 関数 fsync() ext4 よりも ext3 の方がはるかに効率的に動作します。 このアプローチの欠点は、以前と同様に、プログラムのインストールなどの一部の操作が遅くなることです。 詳細はこちらをご覧ください ここで и ここで.

３つ目の問題点は、 fsync(), 2018年に誕生しました。 その後、PostgreSQL プロジェクトのフレームワーク内で、関数が fsync() エラーが発生すると、「ダーティ」ページを「クリーン」としてマークします。 その結果、次の呼び出しは fsync() そのようなページでは何もしません。 このため、変更されたページはメモリに保存され、ディスクに書き込まれることはありません。 アプリケーションは一部のデータがディスクに書き込まれたと考えますが、実際にはそうではないため、これは本当に悲惨です。 このような失敗 fsync() まれなケースですが、そのような状況ではアプリケーションは問題に対処するためにほとんど何もできません。 最近では、これが発生すると、PostgreSQL やその他のアプリケーションがクラッシュします。 それはの記事「アプリケーションは fsync 障害から回復できますか?」で、この問題について詳しく説明しています。 現在、この問題に対する最善の解決策は、フラグを指定して Direct I/O を使用することです。 O_SYNC または旗を持って O_DSYNC。 このアプローチでは、システムは特定のデータ書き込み操作を実行するときに発生する可能性のあるエラーを報告しますが、このアプローチではアプリケーションがバッファ自体を管理する必要があります。 詳細についてはこちらをご覧ください ここで и ここで.

O_SYNC フラグと O_DSYNC フラグを使用してファイルを開く

永続的なデータ ストレージを提供する Linux メカニズムの説明に戻りましょう。 つまり、フラグの使用について話しています。 O_SYNC またはフラグ O_DSYNC システムコールを使用してファイルを開くとき 開いた（）。 このアプローチでは、各データ書き込み操作は各コマンドの後であるかのように実行されます。 write() システムにはそれぞれコマンドが与えられます fsync() и fdatasync()。 で POSIX仕様 これは、「同期 I/O ファイル整合性の完了」および「データ整合性の完了」と呼ばれます。 このアプローチの主な利点は、データの整合性を確保するために実行する必要があるシステムコールは XNUMX つではなく XNUMX つだけであることです (たとえば、- write() и fdatasync()）。 このアプローチの主な欠点は、対応するファイル記述子を使用するすべての書き込み操作が同期されるため、アプリケーション コードを構造化する機能が制限される可能性があることです。

O_DIRECT フラグを使用したダイレクト I/O の使用

システムコール open() 旗をサポートします O_DIRECT、オペレーティング システムのキャッシュをバイパスし、I/O 操作を実行し、ディスクと直接対話するように設計されています。 これは、多くの場合、プログラムによって発行された書き込みコマンドが、ディスクを操作するためのコマンドに直接変換されることを意味します。 ただし、一般に、このメカニズムは次の機能に代わるものではありません。 fsync() または fdatasync()。 実際には、ディスク自体は次のことができます。 遅延またはキャッシュ データを書き込むための適切なコマンド。 さらに悪いことに、一部の特殊なケースでは、フラグの使用時に実行される I/O 操作が O_DIRECT, 放送 従来のバッファ操作に移行します。 この問題を解決する最も簡単な方法は、フラグを使用してファイルを開くことです O_DSYNCこれは、各書き込み操作の後に呼び出しが続くことを意味します。 fdatasync().

XFS ファイルシステムが最近、「高速パス」を追加したことが判明しました。 O_DIRECT|O_DSYNC-データレコード。 ブロックが次を使用して上書きされる場合、 O_DIRECT|O_DSYNCの場合、デバイスがサポートしている場合、XFS はキャッシュをフラッシュする代わりに FUA 書き込みコマンドを実行します。 ユーティリティを使用してこれを確認しました blktrace Linux 5.4/Ubuntu 20.04 システム上。 このアプローチは、ディスクに最小限のデータを書き込み、XNUMX つの操作 (書き込みとキャッシュのフラッシュ) ではなく XNUMX つの操作を使用するため、より効率的になります。 へのリンクを見つけました パッチ このメカニズムを実装する 2018 カーネル。 この最適化を他のファイルシステムに適用することについては議論がありますが、私の知る限り、現時点でこの最適化をサポートしているファイルシステムは XFS だけです。

sync_file_range() 関数

Linuxにはシステムコールがある 同期ファイル範囲()これにより、ファイル全体ではなく、ファイルの一部のみをディスクにフラッシュできます。 この呼び出しは非同期フラッシュを開始し、完了を待ちません。 しかし、への参照では、 sync_file_range() このコマンドは「非常に危険」であると言われています。 使用はお勧めしません。 特徴と危険性 sync_file_range() で非常によく説明されています これ 材料。 特に、この呼び出しでは、カーネルがいつ「ダーティ」データをディスクにフラッシュするかを制御するために RocksDB を使用しているようです。 しかし同時に、安定したデータストレージを確保するために、 fdatasync()。 で コード RocksDB には、この件に関して興味深いコメントがいくつかあります。 たとえば、次のような呼び出しになります。 sync_file_range() ZFS を使用する場合、データはディスクにフラッシュされません。 経験上、めったに使用されないコードにはバグが含まれている可能性があります。 したがって、どうしても必要な場合を除き、このシステム コールを使用しないことをお勧めします。

データの永続性を確保するためのシステムコール

私は、永続的な I/O 操作を実行するために使用できるアプローチが XNUMX つあるという結論に達しました。 それらはすべて関数呼び出しが必要です fsync() ファイルが作成されたディレクトリの場合。 アプローチは次のとおりです。

1. 関数呼び出し fdatasync() または fsync() 関数の後 write() (使った方が良い fdatasync()).
2. フラグで開かれたファイル記述子の操作 O_DSYNC または O_SYNC （もっと良い - 旗を持って O_DSYNC).
3. コマンドの使用法 pwritev2() 旗付き RWF_DSYNC または RWF_SYNC (できれば旗付き RWF_DSYNC).

パフォーマンスノート

調査したさまざまなメカニズムのパフォーマンスを注意深く測定しませんでした。 彼らの仕事のスピードに私が気づいた違いは非常に小さいです。 これは、私が間違っている可能性があり、他の条件では同じことが異なる結果を示す可能性があることを意味します。 まず、何がパフォーマンスに大きな影響を与えるかについて説明し、次に何がパフォーマンスに影響を与えないかについて説明します。

1. ファイル データを上書きする方が、ファイルにデータを追加するよりも高速です (パフォーマンスが 2 ～ 100% 向上する可能性があります)。 ファイルにデータを添付するには、システムコールの後であっても、ファイルのメタデータに追加の変更が必要です fallocate()ただし、この効果の大きさは異なる場合があります。 最高のパフォーマンスを得るために、電話することをお勧めします fallocate() 必要なスペースを事前に割り当てます。 次に、このスペースを明示的にゼロで埋めて呼び出す必要があります。 fsync()。 これにより、ファイル システム内の対応するブロックが「未割り当て」ではなく「割り当て済み」としてマークされます。 これにより、パフォーマンスがわずかに (約 2%) 向上します。 また、一部のディスクでは、最初のブロック アクセス操作が他のディスクよりも遅い場合があります。 これは、スペースをゼロで埋めると、パフォーマンスが大幅に (約 100%) 向上する可能性があることを意味します。 特に、これはディスクで発生する可能性があります。 AWS EBS （これは非公式のデータです、私はそれらを確認できませんでした）。 ストレージについても同様です。 GCP 永続ディスク (そしてこれはすでに公式情報であり、テストによって確認されています)。 他の専門家も同様のことを行っている 観察異なるディスクに関連しています。
2. システムコールが少ないほど、パフォーマンスは向上します (向上は約 5% になる可能性があります)。 挑戦のようですね open() 旗付き O_DSYNC または電話する pwritev2() 旗付き RWF_SYNC より速い通話 fdatasync()。 ここでのポイントは、このアプローチでは、同じタスクを解決するために実行する必要があるシステム コールの数が少なくなる (XNUMX つの呼び出しではなく XNUMX つの呼び出し) という事実が影響しているのではないかと思います。 ただし、パフォーマンスの違いは非常に小さいため、簡単に無視して、ロジックが複雑にならないものをアプリケーションで使用できます。

持続可能なデータ ストレージのトピックに興味がある場合は、次の役立つ資料を参照してください。

• I/Oアクセス方式 — 入出力メカニズムの基本の概要。
• データがディスクに確実に到達するようにする - アプリケーションからディスクに移動する途中でデータに何が起こるかについての話。
• 含まれているディレクトリをいつ fsync する必要があるか - いつ申請するかという質問に対する答え fsync() ディレクトリ用。 簡単に言うと、新しいファイルを作成するときにこれを行う必要があることがわかりました。この推奨の理由は、Linux では同じファイルへの参照が多数存在する可能性があるためです。
• Linux 上の SQL Server: FUA の内部構造 - ここでは、Linux プラットフォーム上の SQL Server でデータ永続性がどのように実装されるかについて説明します。 ここには、Windows と Linux のシステム コール間の興味深い比較がいくつかあります。 私が XFS の FUA 最適化について学んだのは、この資料のおかげだったとほぼ確信しています。

ディスクに安全に保存されていると思っていたデータを紛失したことがありますか?

出所： habr.com