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

＃＃＃概要＃＃＃

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 サイトの他の関連記事を参照してください。