ext4マウントオプションデータモード：ジャーナルオーダードライトバック
Ext4 Mount Option Data Mode
Ext4は、ジャーナルの動作を区別するために3つのDATAモードをサポートしています。 ext4ジャーナルはPostgreSQLXLOGに似ており、ディザスタリカバリとデータの整合性を確保するために使用できます。ファイルはext4の2つの部分に保存され、1つはファイルのメタデータで、もう1つはデータです。メタデータとデータの操作ログジャーナルも個別に管理されます。データのジャーナルをログに記録せずに、ext4にジャーナルのジャーナルを記録させることができます。これは、ext4をマウントするときのデータパラメータに依存します。 1. data = journal すべてのデータは、作成される前にジャーナルにコミットされます メインファイルシステムに書き込まれます。有効化 このモードでは、遅延割り当てが無効になり、 O_DIRECTサポート。ファイルシステムにデータを書き込む前に、メタデータとデータのジャーナルが配置されるのを待つ必要があります。パフォーマンスが最悪で、ファイル操作のdelalloc、O_DIRECTフラグをサポートしていません（man openを参照）。 fsyncが呼び出されると、ファイルシステム操作には次のシーケンスが含まれます。fsync（データジャーナル）-> fsync（メタデータジャーナル）-> fsync（データ）-> fsync（メタデータ）メタデータを長時間ロックする fsync（メタデータジャーナル） およびfsync（メタデータ） ？
2. data = ordered （*） すべてのデータはメインファイルに直接強制的に送信されます メタデータがコミットされる前のシステム ジャーナル。このモードでは、データのジャーナルは記録されず、メタデータのジャーナルログのみが記録されますが、メタデータのジャーナルを書き込む前に、まずデータが配置されていることを確認する必要があります。fsyncが呼び出されると、ファイルシステム操作には次のシーケンスが含まれます。 fsync（メタデータジャーナル）->Fsync（data）（データが最初に配置されることを確認してください）-> fsync（metadata）メタデータを長時間ロックしますfsync（メタデータジャーナル） およびfsync（メタデータ） ？
3. data = writeback データの順序は保持されません。データが書き込まれる可能性があります メタデータが処理された後、メインファイルシステムに ジャーナルにコミットしました。データジャーナルは記録されず、メタデータジャーナルのみが記録されます。また、データがメタデータの前に配置されることを保証するものではありません。fsyncが呼び出されると、ファイルシステム操作には次のシーケンスが含まれます。 fsync（メタデータジャーナル） -> fsync（メタデータ）
また、メタデータ操作は単一のext4ファイルシステムでシリアルであるため、ユーザーのメタデータ操作がブロックされると、同じファイルシステムのメタデータのすべての操作に影響することに注意してください。メタデータの書き込みに夢中になっているユーザー（たとえば、大きなファイルを大きなバッチで作成したり、fsyncを呼び出したりする）など、ライトバックがあってもこれが発生する可能性があります。
古典的な例：fsync（data）が遅い場合、他の人が待機中のメタデータを書き込む原因になります（メタデータの書き込みには、新しいファイルの作成、ファイルの読み取りと書き込み（ファイルサイズの変更）など、多くのことが含まれます）。プロセススタックを表示します。10249はfsyncです：
[root@xxxxx ~]# cat /proc/10249/stack [] do_get_write_access+0x29d/0x520 [jbd2] [] jbd2_journal_get_write_access+0x31/0x50 [jbd2] [] __ext4_journal_get_write_access+0x38/0x80 [ext4] [] ext4_reserve_inode_write+0x73/0xa0 [ext4] [] ext4_mark_inode_dirty+0x4c/0x1d0 [ext4] [] ext4_dirty_inode+0x40/0x60 [ext4] [] __mark_inode_dirty+0x3b/0x160 [] file_update_time+0xf2/0x170 [] __generic_file_aio_write+0x210/0x470 [] generic_file_aio_write+0x6f/0xe0 [] ext4_file_write+0x61/0x1e0 [ext4] [] do_sync_write+0xfa/0x140 [] vfs_write+0xb8/0x1a0 [] sys_write+0x51/0x90 [] system_call_fastpath+0x16/0x1b [] 0xffffffffffffffff 10255 ブロックされた新しいファイルの作成：
[root@xxxxx ~]# cat /proc/10255/stack [] do_get_write_access+0x29d/0x520 [jbd2] [] jbd2_journal_get_write_access+0x31/0x50 [jbd2] [] __ext4_journal_get_write_access+0x38/0x80 [ext4] [] ext4_new_inode+0x3d5/0x1260 [ext4] [] ext4_create+0xc3/0x150 [ext4] [] vfs_create+0xb4/0xe0 [] do_filp_open+0xb2f/0xd60 [] do_sys_open+0x69/0x140 [] sys_open+0x20/0x30 [] system_call_fastpath+0x16/0x1b [] 0xffffffffffffffff 【解決策】1.カーネルブラシのダーティページとウェイクアップ時間の比率を調整することで、カーネルはダーティページを頻繁に回復できるため、上記の問題の可能性を減らすことができますが、これには長所と短所があります。関連パラメーター：
[root@xxxxx group1]# sysctl -a|grep dirty vm.dirty_background_ratio = 0 vm.dirty_background_bytes = 1638400 vm.dirty_ratio = 50 vm.dirty_bytes = 0 vm.dirty_writeback_centisecs = 100 vm.dirty_expire_centisecs = 3000 関連プロセス：
root@xxxxx> ps -ewf|grep flush root 1100 2 0 Aug14 ? 00:03:18 [flush-253:0] root 1102 2 0 Aug14 ? 00:01:32 [flush-253:2] root 26851 2 0 10:04 ? 00:00:04 [flush-253:1] root 50052 2 0 10:40 ? 00:00:00 [flush-8:0] 調整する前に、これらのパラメーターの意味とLinuxがそれらをどのように処理するかを必ず理解してください。システムはいくつかのカーネルパラメータをキャッシュします（2つは指定されたバイトで、比率に似ています）。1。/ proc / sys / vm / dirty_background_ratioこのファイルは、システムのメモリ全体に到達するダーティデータの割合を示します。この時点で、pdflushプロセスがトリガーされ、ダーティデータがディスクに書き戻されます。デフォルト設定：10ユーザーがwriteを呼び出したときに、システム内のダーティデータがこのしきい値（またはダーティバックグラウンドバイト）、ダーティデータを書き込むためにpdflushプロセスをトリガーしますが、ユーザーの書き込み呼び出しは待機せずにすぐに戻ります。ダーティページへのpdflushの標準は、ダーティページをこのしきい値より低くすることです。 cgroupがユーザープロセスのIOPSを制限している場合でも、それは問題ではありません。2. / proc / sys / vm / dirty_expire_centisecsこのファイルは、ダーティデータがこの値より長くメモリに存在する場合、pdflushプロセスが次回ディスクにデータを書き戻すことを示しています。デフォルト設定：3000（1/100秒）3。/ proc / sys / vm / dirty_ratioこのファイルは、プロセスによって生成されたダーティデータがシステムの合計メモリに達した場合、ユーザープロセスがダーティデータをディスクに書き戻すことを示します。 。デフォルト設定：40ユーザーがwriteを呼び出したときに、システム内のダーティデータがしきい値（またはdirty_bytes）より大きいことがわかった場合、ダーティデータをディスクにフラッシュして戻し、しきい値未満に戻す必要があります。この時点でcgroupがユーザープロセスのIOPSを制限している場合、それは悲劇であることに注意してください。 4. / proc / sys / vm / dirty_writeback_centisecsこのファイルは、定期的に超過するpdflushプロセスのウェイクアップ間隔を示します。Dirty_expire_centisecs時間 ダーティデータはディスクに書き戻されます。デフォルト設定：500（1/100秒）システムは通常、次の3つの場合にダーティページを書き戻します。1。タイミングモード：時間制限付きライトバックは、/ proc / sys / vm / dirty_writeback_centisecsの値が長い間、ライトバックスレッドが開始され、このタイマーによって開始されたライトバックスレッドはメモリにのみ書き戻されます。ダーティタイムが（/ proc / sys / vm / dirty_expire_centisecs / 100）秒を超えています（この値のデフォルトは3000、つまり30秒です）。一般に、dirty_writeback_centisecsの値は500、つまり5秒であるため、システムはデフォルトで5秒でライトバックスレッドを開始し、ダーティタイムが30秒を超えるページを書き戻します。この方法で開始されたライトバックスレッドは、タイムアウトダーティページを書き戻すだけであり、タイムアウトなしではダーティを書き戻さないことに注意してください。ページでは、/ procの2つの値を変更することで、カーネル関数wb_kupdateを表示できます。 2.十分なメモリがない場合：この時点では、すべてのダーティページがディスクに書き込まれるわけではありませんが、空きページが要件を満たすまで、毎回約1024ページが書き込まれます。 3.書き込み時にダーティページが特定の割合を超えていることが判明：ダーティページが/ proc / sys / vm / dirty_background_ratioを超える場合、書き込みシステムコールはpdflushをウェイクアップし、ダーティページの比率が/ proc / sys / vm / dirty_background_ratioよりも低いが、書き込みシステムコールはブロックされないため、すぐに戻ります。システムメモリ内のダーティページの割合が/ proc / sys / vm / dirty_ratioを超えると、システムコールの書き込みがブロックされ、ダーティページの比率が/ proc / sys / vmより低くなるまでダーティページがアクティブに書き戻されます。 / dirty_ratioビッグデータプロジェクトの感想：1書き込み量が膨大な場合、システムキャッシュの自動キャッシュバックメカニズムは期待できません。 fsyncまたはsyncを呼び出すには、アプリケーション層を使用するのが最適です。書き込み量が多く、システムキャッシュの速度を自動的に超えた場合でも、システムのダーティページレートが/ proc / sys / vm / dirty_ratioを超える可能性があります。このとき、システムは後続の書き込み操作をブロックします。私たちのアプリケーションに受け入れられなくなるまでに5分かかる場合があります。したがって、1つの推奨される方法は、アプリケーション層の適切なタイミングでfsyncを呼び出すことです。 2主要なパフォーマンスについては、システムキャッシュの役割に依存しないことをお勧めします。パフォーマンス要件が比較的高い場合は、システムキャッシュが外部からの影響が大きすぎるため、アプリケーション層にキャッシュを実装することをお勧めします。世界、多分いつ、システムキャッシュが洗い流される。 3論理設計では、システムキャッシュを使用するための要件を見つけることが非常に適しています。ロジック内の高層ステッカーの場合、アプリケーション層のキャッシュの実装は非常に複雑であり、その数は非常に少ないです。リクエストのこの部分は、機能するシステムキャッシュに依存する可能性があります。ただし、アプリケーション層のキャッシュと連携する必要があります。アプリケーション層のキャッシュは、高層でないステッカーのほとんどのリクエストをキャッシュできます。これが行われた後、システムioのプログラム全体が主に高層ビルに投稿されます。この場合、システムキャッシュは適切に機能します。
2.別のアイデアは、最初にfdatasyncを呼び出し、次にfsyncを呼び出して、輻輳時間を短縮することです。 fdatasyncの一部のシナリオではメタデータをブラッシングする必要はありませんが、一部のシーンではメタデータをブラッシングする必要があるため（たとえば、ファイルサイズの変更に関連する）、このソリューションはすべてのシナリオに適しているわけではありません。
最後のアイデアは、ブラシをできるだけ速くし、データがディスクにブラシをかけられず、データがスキャンされるのを待つ時間を避けるようにすることです。 cgroupを使用してIOPSシナリオを制限するなど、一部のアプリケーションシナリオでは、細心の注意を払う必要があります。 （このシナリオでは、カーネルプロセスのIOPSは一般に制限されていないため、カーネルプロセスはダーティページのブラッシングに非常に効果的です）。
詳細な説明：
Data Mode ========= There are 3 different data modes: * writeback mode In data=writeback mode, ext4 does not journal data at all. This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode - metadata journaling. A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash. This mode will typically provide the best ext4 performance. * ordered mode In data=ordered mode, ext4 only officially journals metadata, but it logically groups metadata information related to data changes with the data blocks into a single unit called a transaction. When it's time to write the new metadata out to disk, the associated data blocks are written first. In general, this mode performs slightly slower than writeback but significantly faster than journal mode. * journal mode data=journal mode provides full data and metadata journaling. All new data is written to the journal first, and then to its final location. In the event of a crash, the journal can be replayed, bringing both data and metadata into a consistent state. This mode is the slowest except when data needs to be read from and written to disk at the same time where it outperforms all others modes. Enabling this mode will disable delayed allocation and O_DIRECT support. ext4は、ジャーナルを保存するための追加のジャーナルデバイスの使用をサポートします。これを実行することが確実な場合は、ジャーナルデバイスとしてIOPSパフォーマンスの高いブロックデバイスを使用することをお勧めします。これは、データベースのREDOログで低遅延ブロックデバイスを使用するのと同じです。ジャーナルデバイスは、mkfs.ext4のときに指定できます。
[参照]1.1。 https://www.kernel.org/doc/Documentation/filesystems/ext4.txt 二。 http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/11774-atc13-jeong.pdf 3.男が開いている http://man7.org/linux/man-pages/man2/open.2.html
O_DSYNC Write operations on the file will complete according to the requirements of synchronized I/O data integrity completion. By the time write(2) (and similar) return, the output data has been transferred to the underlying hardware, along with any file metadata that would be required to retrieve that data (i.e., as though each write(2) was followed by a call to fdatasync(2)). See NOTES below. 2.6.33より前のカーネルはo_dsyncをサポートしていないため、最初に使用できるのはfdatasyncとfsyncのみです。
4. man fsync
DESCRIPTION fsync() transfers ('flushes') all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) where that file resides. The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)). Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed. fdatasync() is similar to fsync(), but does not flush modified metadata unless that metadata is needed in order to allow a subsequent data retrieval to be correctly handled. For example, changes to st_atime or st_mtime (respectively, time of last access and time of last modification see stat(2)) do not require flushing because they are not necessary for a subsequent data read to be handled correctly. On the other hand, a change to the file size (st_size, as made by say ftruncate(2)), would require a metadata flush. The aim of fdatasync() is to reduce disk activity for applications that do not require all metadata to be synchronized with the disk. Fsyncはダーティデータとメタデータをディスクにフラッシュし、fdatasyncはダーティデータのみをディスクにフラッシュします（場合によってはメタデータもフラッシュします）。したがって、fsyncを呼び出す前にfdatasyncを呼び出し、ダーティデータをディスクにフラッシュしてから、fsyncを呼び出して、メタデータをロックする時間を短縮できます。