CentOS のジャーナリング ファイル システム ext3 の詳細

＃＃＃概要＃＃＃

1. ログ ファイル システム

2. ext3

の利点

3. ext3

の 3 つのログ モード

4. ログモードを選択します

1. ログ ファイル システム

通常、システムの実行中にファイルのコンテンツが書き込まれる場合、ファイルのメタデータ (権限、所有者、作成、アクセス時刻など) は書き込まれません。ファイルのコンテンツが書き込まれた後にファイルのコンテンツが書き込まれる場合、ファイルメタデータが書き込まれる前に、その時間差の間、システムが異常シャットダウンし、書き込み処理中のファイルシステムが異常アンロードされ、ファイルシステムが不整合な状態になります。再起動時に、Linux は fsck プログラムを実行し、ファイル システム全体をスキャンしてすべてのファイル ブロックが正しく割り当てられているか使用されていることを確認し、破損したディレクトリ エントリを見つけて修復しようとします。ただし、fsck は損傷が修復されることを保証しません。この問題が発生すると、ファイル内の一貫性のないメタデータが失われたファイルのスペースを埋め、ディレクトリ エントリ内のファイル エントリが失われ、ファイルが失われる可能性があります。

ファイル システムの不整合を最小限に抑え、オペレーティング システムの起動時間を短縮するために、ファイル システムは、システム変更を引き起こすレコードを追跡する必要があります。これらのレコードは、ファイル システムとは別の場所に保存されます。それを「ログ」と呼びます。これらのログ レコードが安全に書き込まれると、ログ ファイル システムはそれらを使用してシステム変更の原因となったレコードをクリーンアップし、ファイル システム変更の原因となったセットに編成してデータベース トランザクションに配置し、有効なデータの通常の動作は、システム全体のパフォーマンスと競合しません。システムがクラッシュした場合、または再起動が必要な場合は、ログ ファイルに記録された情報に従ってデータが復元されます。ログ ファイルには定期的なチェックポイントがあるため、通常は非常に整然としています。ファイル システムの設計では、主に効率とパフォーマンスの問題を考慮します。

Linux は、FAT、VFAT、HPFS (OS/2)、NTFS (Windows NT)、UFS、XFS、JFS、ReiserFS、ext2、ext3 などを含む多くのログ ファイル システムをサポートできます。

2. ext3

の利点

ext2 から ext3 に移行する必要があるのはなぜですか?主な理由は、可用性、データの整合性、速度、移行の容易さの 4 つです。

＃＃＃＃＃＃可用性＃＃＃＃＃＃

異常クラッシュ (停電、システムクラッシュ) の後、e2fsck による整合性検証後にのみ ext2 ファイルシステムをマウントして使用できます。 e2fsck の実行時間は主に ext2 ファイル システムのサイズによって異なります。わずかに大きいファイル システム (数十ギガバイト) の検証には時間がかかります。ファイル システム上に多数のファイルがある場合、検証に時間がかかります。数百ギガバイトのファイル システムの検証には 1 時間以上かかる場合があります。これにより、使いやすさが大幅に制限されます。一方、ext3 は、ハードウェア障害が発生しない限り、異常終了した場合でもファイル システムの検証を必要としません。これは、データがファイル システム全体で一貫した方法でディスクに書き込まれるためです。異常なシャットダウン後、ext3 ファイル システムを復元する時間は、ファイル システムのサイズやファイルの数ではなく、一貫性を維持するために必要な「ログ」のサイズによって決まります。デフォルトのログ設定では、回復時間はわずか 1 秒です (ハードウェアの速度によって異なります)。

＃＃＃＃＃＃データの整合性＃＃＃＃＃＃

ext3 ファイル システムを使用すると、異常シャットダウン時のデータ整合性パフォーマンスが確実に保証されます。データ保護の種類とレベルを選択できます。ファイル システムの一貫性を維持しながら、異常なシャットダウン中にファイル システム上のデータが破損することを許容することを選択できます。これにより、状況によっては速度がある程度向上します (すべての状況ではありません)。データの信頼性をファイル システムと一致させるように選択することもできます。これは、クラッシュ後に新しく書き込まれたファイルにデータのガベージが表示されないことを意味します。ファイル システムと一貫したデータの整合性を維持するこの安全なオプションは、デフォルト設定です。 ＃＃＃＃＃＃スピード＃＃＃＃＃＃ ext3 は ext2 よりも多くの回数データを書き込みますが、多くの場合、ext3 は ext2 よりも高速です (高いデータ フロー)。これは、ext3 のロギング機能により、ハードディスクのヘッドの回転が最適化されるためです。 3 つのロギング モードから 1 つを選択して速度を最適化し、一部のデータ整合性を選択的に犠牲にすることができます。最初のモードである data=writeback では、限定的なデータ整合性が提供され、クラッシュ後に古いデータがファイル内に存在することが許可されます。このモードは、特定の状況で速度を向上させることができます。 (ほとんどのジャーナリング ファイル システムでは、このモードがデフォルト設定です。このモードは、ext2 ファイル システムに限定的なデータ整合性を提供し、システム起動時の長いファイル システム検証を避けるためのものです) 2 番目のこのモード、data = orderd (デフォルト) )、データの信頼性とファイル システムの一貫性が維持されます。これは、クラッシュ後に新しく書き込まれたファイルにジャンク データが表示されないことを意味します。 3 番目のモード data=journal では、ほとんどの場合、適度な速度を確保するために、より大きなジャーナルが必要です。また、クラッシュ後の回復にも時間がかかります。ただし、一部のデータベース操作では高速になります。通常の状況では、デフォルト モードを使用することをお勧めします。モードを変更する必要がある場合は、/etc/fstab ファイル内の対応するファイル システムに data=mode オプションを追加してください。詳細については、マウントコマンド(man mountの実行)のオンラインマニュアルmanページを参照してください。

移行が簡単

ハードディスクを再フォーマットせずに ext2 から ext3 に簡単に移行でき、信頼性の高いジャーナリング ファイル システムの利点を享受できます。はい、長くて退屈でエラーが発生しやすい「バックアップ、再フォーマット、復元」操作を行わなくても、ext3 の利点を体験できます。 2 つの移行方法があります:

システムをアップグレードする場合、Red Hat Linux インストーラーが移行を支援します。各ファイル システムの [選択] ボタンをクリックするだけです。

tune2fs プログラムを使用して、既存の ext2 ファイル システムにログ機能を追加します。変換プロセス中にファイル システムがマウントされている場合、ファイル「.journal」はルート ディレクトリに表示されますが、ファイル システムがマウントされていない場合、ファイルはファイル システムに表示されません。ファイル システムを変換するには、tune2fs -j /dev/hda1 (または変換するファイル システムが存在するデバイス名) を実行し、ファイル /etc/fstab 内の ext2 を ext3 に変更します。独自のルート ファイル システムを変換する場合は、initrd を使用して起動する必要があります。 mkinitrd のマニュアルの説明に従ってプログラムを実行し、LILO または GRUB 構成に initrd がロードされていることを確認します (成功しない場合でもシステムは起動できますが、ルート ファイル システムは ext3 ではなく ext2 としてロードされます)。これを確認するには、cat / proc/mounts コマンドを使用できます。) 詳細については、tune2fs コマンドのマニュアル ページのオンライン マニュアルを参照してください (mantune2fs を実行します)。

3. ext3

の 3 つのログ モード

ext3 は複数のログ モードを提供します。つまり、ファイル システムのメタデータの変更であっても、ファイル システムのデータの変更 (ファイル自体への変更を含む) であっても、ext3 ファイル システムはそれをサポートできます。 /etc/fstab ファイル 3 つの異なるロギング モードが有効化されています:

data=ジャーナルログモード

ログ レコードには、ファイル システムを変更したすべてのデータとメタデータが含まれます。これは 3 つの ext3 ジャーナリング モードの中で最も遅いですが、エラーの可能性は最小限に抑えられます。 「data=journal」モードを使用すると、ext3 は各変更をファイル システムに 2 回、ジャーナルに 1 回書き込む必要があるため、ファイル システム全体のパフォーマンスが低下します。すべての新しいデータは最初にログに書き込まれ、その後検索されます。事故が発生した後、ログを再生してデータとメタデータを一貫した状態に戻すことができます。 ext3 のメタデータとデータの更新が記録されるため、これらのログはシステムの再起動時に有効になります。

data=順序付きログ モード (デフォルト)

変更されたファイル システムのメタデータのみが記録され、オーバーフロー ファイル データはディスクに追加する必要があります。これはデフォルトの ext3 ロギング モードです。このモードでは、ファイル システムへの書き込みとログへの書き込みの間の冗長性が軽減されるため、高速になります。ファイル データの変更はログに記録されませんが、変更は実行する必要があり、ext3 デーモン プログラムによって制御されます。関連するファイル システムのメタデータの変更、つまり、メタデータを記録する前にファイル システム データを変更する必要があります。これにより、システムのパフォーマンス (速度) がわずかに低下しますが、ファイル システム内のファイル データの一貫性が保証されます。対応するファイル システムのメタデータの同期。

data=ライトバックログモード

変更されたファイル システムのメタデータのみを記録します ただし、標準のファイル システムによれば、ファイル システムの一貫性を維持するために、書き込みプログラムはディスク上のファイル データの変更を記録する必要があります。これは最速の ext3 ジャーナリング モードです。ファイル サイズやディレクトリ情報などのファイル データに関連する更新を待たずにメタデータの変更のみを記録するため、ファイル データの更新とメタデータの変更の記録を非同期にすることができます。つまり、ext3 は非同期ログをサポートします。システムをシャットダウンすると更新データがディスクに書き込めず不整合になるという欠点があり、この問題はまだ解決されていません。

ログモードによって違いはありますが、設定方法は同じで便利です。ログ モードは、ext3 ファイル システムを使用して指定できます。これは、起動時に /etc/fstab によって行われます。たとえば、data=writeback ログ モードを選択した場合、次の設定を行うことができます。

/dev/hda5 /opt ext3 data=ライトバック 1 0

一般に、data=ordered ログ モードは ext3 ファイル システムのデフォルト モードです。

ログ方法を指定するには、次の方法を使用できます:

1 /etc/fstab のオプション フィールドに data=journal などの適切な文字列を追加します。

# /dev/sda3 /var ext3 デフォルト、data=writeback 1 2

2 mount を呼び出すときに、-o data=journal コマンド ライン オプションを直接指定します。

# mount -o data=journal /dev/sdb1 /mnt

特定のファイル システムのログ モードを確認したい場合、どのようにクエリを実行すればよいでしょうか? ここでは dmesg コマンドを使用できます:

# dmesg | grep -B 1 "マウントされたファイルシステム"

kjournald を開始しています。コミット間隔は 5 秒です

EXT3-fs: 順序付きデータ モードでマウントされたファイルシステム。

--

EXT3 FS on sda1、内部ジャーナル

EXT3-fs: 順序付きデータ モードでマウントされたファイルシステム。

--

sdb1 上の EXT3 FS、内部ジャーナル

EXT3-fs: ジャーナル データ モードでマウントされたファイルシステム。

--

sdb1 上の EXT3 FS、内部ジャーナル

EXT3-fs: ライトバック データ モードでマウントされたファイルシステム。

4. ログモードを選択します

＃＃＃＃＃＃スピード＃＃＃＃＃＃

典型的なケースでは、オプション data=writeback を使用すると速度が大幅に向上しますが、同時にデータの一貫性の保護が低下します。このような場合、データ整合性保護は基本的に ext2 ファイル システムの場合と同じですが、通常の動作中にシステムがファイル システムの整合性を継続的に維持する点が異なります (これは、他のジャーナリング ファイル システムで使用されるジャーナリング モードです)。これには、頻繁な共有書き込み操作だけでなく、多数の小さな電子メール メッセージの送信など、多数の小さなファイルの頻繁な作成と削除も含まれます。 ext2 から ext3 に切り替えて、アプリケーションのパフォーマンスが大幅に低下した場合は、オプション data=writeback がパフォーマンスの向上に役立つ可能性があります。高価なデータ整合性保護対策を講じていなくても、ext3 の利点を享受できます (ファイル システムは常に整合性が保たれます)。 Red Hat は、ext3 のパフォーマンスのいくつかの側面を改善するための作業を現在も行っているため、ext3 のパフォーマンスのいくつかの側面は将来改善される可能性があります。これは、今すぐ data=writeback を選択したとしても、新しいバージョンの変更が作業に関連するかどうかを判断するために、data=journal のデフォルト値を使用して将来のバージョンを再テストする必要があることも意味します。 ＃＃＃＃＃＃データの整合性＃＃＃＃＃＃ ほとんどの場合、ユーザーはファイルの最後にデータを書き込みます。一部の場合 (データベースなど) にのみ、ユーザーは既存のファイルの途中にデータを書き込みます。既存のファイルを上書きする場合でも、最初にファイルを切り詰めてから、ファイルの末尾からデータを書き込むことで実行されます。 data=owned モードでは、ファイルの書き込み中にシステムがクラッシュすると、データ ブロックが部分的に上書きされる可能性がありますが、書き込みプロセスは完了していないため、システムにはどのファイルにも属さない不完全なデータ ブロックが残ります。 data=owned モードでは、クラッシュ後に順序付けされていないデータ ブロックが残る唯一の状況は、クラッシュ中にプログラムがファイルを書き換えている場合です。この場合、プログラムが fsync() と O_SYNC を使用して特定の順序で書き込みを強制しない限り、書き込み順序の絶対的な保証はありません。

ext3 ファイル システムには、キャッシュ内のデータをハード ディスクにフラッシュする方法も含まれます。 kupdate プロセスによる定期的なフラッシュを実装します。デフォルトでは、5 秒ごとにチェックし、30 秒を超えるダーティ データをハードディスク

にフラッシュします。 as 3.0 では、/proc/sys/vm/bdflush を変更することで目的を達成できます。 as 4.0 では、/proc/sys/vm/dirty_writeback_centisecs および /proc/sys/vm/dirty_expire_centisecs を変更することで目的を達成できます。

デフォルトは順序付けモードであるため、このモードでは、IO が最初にデータ ファイルを書き込むと、次にログ ファイルが書き込まれます。データ ファイルの書き込み後、ログ ファイルの書き込み前にシステムがクラッシュすると、データのこの部分が失われますが、Oracle であっても MySQL であっても、データベースではこれは絶対に許可されません。したがって、

データベース書き込みの場合、各書き込み操作は最初にページキャッシュに書き込まれ、次にカーネルスレッドにバッファをハードディスクにフラッシュするように通知され、次にメタデータがログに書き込まれ、最後に成功した操作が行われます。書き込み操作が返されます。このように、データベースへの書き込み操作は、明らかにベア デバイスへの書き込みほど高速ではありません。

Ext3 を使用してデータベースを実行する場合は、ログ モードをジャーナル モードに設定すると、パフォーマンスが向上するはずです (テストされていません。理論的な分析は次のようになります)。ジャーナル モードでのデータベースへの書き込み操作の場合、データとファイル システムの変更は最初にログに直接書き込まれ (直接書き込みはキャッシュをバイパスするため、パフォーマンスが向上します)、次にデータがキャッシュに書き込まれ、次にkupdate プロセスは、ハード ドライブのデータを更新します。対照的に、DB については、以前のものよりもパフォーマンスが高速になるはずです。

さらに、MySQL の sync_binlog パラメーターを次に示します。このパラメータが 1 に設定されている場合は、Oracle の書き込み IO と同様に、binlog ファイルが書き込まれるたびに、同時にハードディスクにフラッシュされることを意味します。このパラメータをオフにすると、OS によって管理される、つまり 5 秒ごとにチェックされ、30 秒前の古いデータが見つかった場合はハードディスクにフラッシュされます。 innodb_flush_log_at_trx_commit パラメータには、ハードディスクのフラッシュの問題も含まれます。

ext2 の拡張バージョンである ext3 は、スーパーブロック、inode、グループ記述子、および ext2 で使用されるその他のデータ構造とほぼ同一であるため、ext3 は ext2 と前方互換性があります。 ext2 ファイル システム データをバックアップせずに、次を使用できます: 1

#tune2fs –j/dev/sd1 パーティションをアンマウントせずに、ext2 ファイル システムを ext3 ファイル システムに直接変換します。

ファイルの編集中に突然停電が発生したり、システムがロックされて強制的に再起動されたりした場合、どのような結果が生じるでしょうか?最悪の場合、ファイル コンテンツの一部が失われ、最悪の場合、ファイル コンテンツ全体が台無しになり、さらに悪いことにはファイル システムが直接クラッシュします。これはなんとひどいことだろう。 Linux が正常にシャットダウンすると、ファイル システムのアンインストールを示す印刷メッセージが表示されます。異常なシャットダウンにより、ファイル システムの不整合が生じます。この不整合は、システムの再起動フェーズ中にファイル システムがマウントされるときに発見され、その後、それを修復してみてください。残念ながら、ストレージ デバイスの容量が増加するにつれて、そのような修復に必要な時間はますます法外なものになります。

Ext3 の最大の特徴は、ext2 をベースにログ機能を追加したことです。そのため、ext3 ファイル システムはログ ファイル システムと呼ばれることが多いですが、ログ ファイル システムには ext3 だけでなく、JFS、reiserFS、XFS も含まれます。 Windows でよく見かける NTFS です。

Ext3 のロギング機能は主に、その下の「ジャーナリング ブロック デバイス層」という名前の、JBD (ジャーナリング ブロック デバイス層、略して JBD) と呼ばれる中間デバイスに依存しています。 JBD はファイル システム仕様の一部ではありません。ext3 ファイル システム仕様とは何の関係もありません。JBD は、ファイル システム トランザクション処理機能の実装の基礎です。つまり、JBD は、任意のブロック デバイスにログを記録するという特別な目的を実装するように設計されています (抽象化すればするほど、トランザクションとは何ですか? ⊙﹏⊙….)

トランザクションに関しては、データベース開発やデータ運用保守の経験のある学生であれば必ず馴染みます。ここでは概念には固執しませんし、学術的な定義にも固執しません。 トランザクションの主な機能は操作のアトミック性を確保することであることを誰もが知っている限りです。この文をどう理解すればいいでしょうか？たとえば、金融システムでは、X 元を口座 A から口座 B に送金する必要があります。この企業は、X 元がアカウント A から正常に送金され、X 元がアカウント B に正常に追加されることを確認する必要があります。この 2 つの操作が同時に成功した場合にのみ転送が成功し、どちらかの操作が失敗した場合はビジネスを終了する必要があります。アカウント A からの X 元の送金が成功し、アカウント B への書き込み時にエラーが発生した場合、アカウント A から送金された X 元をアカウント A に返却する必要があります。さらに極端な状況として、アカウント A のデータがさまざまな理由で崩壊した場合、データベースのトランザクション メカニズムはアカウント A の X 元が失われないようにする必要があります。これがデータベース ビジネス オペレーションのアトミック性です。ログ ファイル システムでは、ファイル データ操作のアトミック性が JBD によって保証されており、Ext3 は JBD の API を「フックする」ことでログ機能を実装します。 JBD 層自体のコードはそれほど多くありませんが、非常に複雑なソフトウェア部分であるため、ここでは説明せず、機会があれば実際に試してみましょう。

ログ ファイル システムは当然ログを記録する必要があり、ログには記憶領域も必要です。したがって、ログ ファイル システムは、ログ情報を保存するためだけに、ストレージ メディア上に特別な領域を開きます。

画像を使用して、ext3 の基礎となるレイアウトを簡単に説明します。

以上がCentOS のジャーナリング ファイル システム ext3 の詳細の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。