拡張子3

ext3、またはthird extended filesystem は、Linux カーネルで一般的に使用されているジャーナリングされたファイルシステムです。これは、多くの一般的なLinux ディストリビューションのデフォルトのファイルシステムでした。Stephen Tweedie は、1998 年の論文「Journaling the Linux ext2fs Filesystem」で、 ext2 の拡張に取り組んでいることを初めて明らかにし、その後、1999 年 2 月のカーネルメーリングリストの投稿でそのことが明らかになりました。このファイルシステムは、2001 年 11 月に 2.4.15 以降、メインラインの Linux カーネルに統合されました。^{[3] [4] [5]} ext2 に対する主な利点はジャーナリングであり、これにより信頼性が向上し、不正なシャットダウン後にファイルシステムをチェックする必要がなくなります。その後継はext4です。^[6]

ext3 のパフォーマンス (速度) は、競合する Linux ファイルシステム (ext4、JFS、ReiserFS、XFSなど) に比べると劣りますが、ext3 には、データのバックアップや復元をせずに ext2 からインプレースアップグレードできるという大きな利点があります。ベンチマークによると、ext3 は ReiserFS や XFS よりも CPU パワーをあまり消費しません。^{[7] [8]}また、比較的シンプルでテストベースが広いため、他の Linux ファイルシステムよりも安全であると考えられています。^{[9] [10]}

ext3 は ext2 に次の機能を追加します。

• ジャーナル​
• オンラインファイルシステムの拡張
• 大規模ディレクトリのHTreeインデックス^[11]

これらの機能がなければ、ext3 ファイル システムはいずれも有効な ext2 ファイル システムでもあります。このため、ext2 ファイル システムの保守と修復に使用できる、十分にテストされた成熟したファイル システム保守ユーティリティを、大きな変更を加えることなく ext3 でも使用できます。ext2 ファイル システムと ext3 ファイル システムは、同じ標準ユーティリティ セット ( e2fsprogs)を共有しており、これにはfsckツールが含まれています。この密接な関係により、2 つのファイル システム間の変換 (ext3 への変換と ext2 への変換の両方) も簡単になります。

ext3 には、動的なinode割り当てやエクステントなどの「最新の」ファイルシステム機能が欠けています。この状況は、時には不利になることもありますが、回復可能性の点では大きな利点となります。ファイルシステムのメタデータはすべて固定された既知の場所にあり、データ構造には冗長性があります。重大なデータ破損の場合、ext2 または ext3 は回復できる可能性がありますが、ツリーベースのファイルシステムは回復できない可能性があります。

ext3の最大ブロック数は2 ³²です。ブロックのサイズは変化する可能性があり、ファイルの最大数とファイルシステムの最大サイズに影響します。^[12]

Linux の ext3 実装では、 次の 3 つのレベルのジャーナリングが利用できます。

ジャーナル（リスクが最も低い）

メタデータとファイルの内容は、メインファイルシステムにコミットされる前にジャーナルに書き込まれます。ジャーナルはディスク上で比較的連続しているため、ジャーナルに十分なスペースがあればパフォーマンスが向上します。そうでない場合は、データを2回（1回はジャーナルに、もう1回はファイルシステムのメイン部分に）書き込む必要があるため、パフォーマンスが低下します。^[13]

命令あり（中程度のリスク）

ジャーナル化されるのはメタデータだけです。ファイルの内容はジャーナル化されませんが、関連するメタデータがジャーナルでコミット済みとしてマークされる前に、ファイルの内容がディスクに書き込まれることが保証されます。これは多くの Linux ディストリビューションのデフォルトです。ファイルの書き込み中または追加中に停電またはカーネル パニックが発生した場合、ジャーナルは新しいファイルまたは追加されたデータが「コミット」されていないことを示すため、クリーンアップ プロセスによって消去されます。(したがって、追加および新しいファイルは、「ジャーナル化」レベルと同じレベルの整合性保護を持ちます。) ただし、上書きされるファイルは、ファイルの元のバージョンが保存されていないため破損する可能性があります。したがって、どちらか一方を復元するための十分な情報がないまま、新しいデータと古いデータの中間状態になることがあります (新しいデータはディスクに完全には書き込まれず、古いデータはどこにも保存されません)。さらに悪いことに、書き込みの順序がディスクのハードウェアに委ねられているため、中間状態では古いデータと新しいデータが混在する可能性があります。^{[13] [14]}

ライトバック（最もリスクが高い）

ジャーナル化されるのはメタデータのみで、ファイルの内容はそうではありません。内容は、ジャーナルが更新される前または後に書き込まれる可能性があります。その結果、クラッシュ直前に変更されたファイルは破損する可能性があります。たとえば、追加されるファイルは、ジャーナルで実際よりも大きいとマークされ、最後にゴミが発生します。ジャーナル回復後に、ファイルの古いバージョンが予期せず表示されることもあります。多くの場合、データとジャーナルの同期がない方が高速です。JFS はこのレベルのジャーナリングを使用しますが、書き込まれていないデータによる「ゴミ」は再起動時にゼロにされます。XFS もこの形式のジャーナリングを使用します。

これら 3 つのモードのいずれにおいても、クラッシュ後でもファイル システムの内部構造の一貫性が保証されます。いずれの場合も、システムがクラッシュしたときに変更されていたファイルまたはディレクトリのデータ コンテンツのみが影響を受け、残りは回復後もそのまま残ります。

ext3 は以前の ext2 との下位互換性を目指しているため、ディスク上の構造の多くは ext2 と似ています。その結果、ext3 にはエクステント、inodeの動的割り当て、ブロックのサブ割り当てなどの最新の機能が欠けています。^[15]ディレクトリには最大 31998 のサブディレクトリを含めることができます。これは、inode には最大 32,000 のリンクを含めることができるためです (各直接サブディレクトリは、".." 参照内の親フォルダ inode リンク カウンターを増加させます)。^[16]

ext3 では、現在の Linux ファイルシステムのほとんどと同様に、ファイルシステムが書き込み用にマウントされている間は、システム ツール " fsck " を使用しないでください。^[6]すでに読み取り/書き込みモードでマウントされているファイルシステムをチェックしようとすると、ファイルシステム メタデータの不整合が (非常に高い確率で) 検出されます。ファイルシステム メタデータが変更されている場合、fsck は変更を適用して "不整合な" メタデータを "整合性のある" 状態にしようとしますが、不整合を "修正" しようとすると、ファイルシステムが破損します。

ファイルシステムレベルで動作するオンラインの ext3デフラグツールは存在しません。オフラインの ext2 デフラグツールは存在しますe2defrag。ただし、e2defragファイルシステムでオンになっている機能ビットによっては、データが破壊される可能性があります。また、新しい ext3 機能の多くを処理する方法がわかりません。^[17]

^{ユーザ空間のデフラグツールには、Shake [18]}や defrag ^{[19] [20]}などがあります。Shakeは、ファイル全体のスペースを 1 つの操作として割り当てることにより動作し、通常、アロケータは連続したディスク領域を見つけます。同時に使用されるファイルがある場合、Shake はそれらを隣り合わせて書き込もうとします。Defrag は、各ファイルをそれ自体にコピーすることにより動作します。ただし、この戦略は、ファイルシステムに十分な空き領域がある場合にのみ機能します。ext3 用の真のデフラグツールは存在しません。^[21]

しかし、Linux システム管理者ガイドには、「現代の Linux ファイルシステムは、連続したセクターに保存できない場合でも、ファイル内のすべてのブロックを近くに保つことで断片化を最小限に抑えます。ext3 などの一部のファイルシステムは、ファイル内の他のブロックに最も近い空きブロックを効果的に割り当てるため、Linux システムでは断片化を心配する必要はありません。」と記載されています。^[22]

ext3はファイルの断片化に耐性がありますが、時間の経過とともに、または大きなファイルをゆっくりと書き込むなどの特定の使用パターンにより、断片化される可能性があります。^{[23] [24]}そのため、ext4（ext3の後継）にはオンラインファイルシステムデフラグユーティリティe4defrag ^[25]があり、現在はエクステント（連続したファイル領域）をサポートしています。

ext3は削除されたファイルの回復をサポートしていません。ext3ドライバはクラッシュ安全性の理由から ファイルのinodeを消去することで積極的にファイルを削除します^{[26] 。}

ファイルシステムジャーナル分析を使用して削除または失われたファイルを回復するためのいくつかの技術^[27]といくつかの無料^[28]およびプロプライエタリ^[29]ソフトウェアがまだ存在しますが、それらは特定のファイルの回復を保証するものではありません。

e3compr ^{[30]は透過的な}圧縮を行うext3の非公式パッチです。これはe2comprの直接の移植であり、まださらなる開発が必要です。アップストリームカーネルでコンパイルおよび起動は良好ですが^{[引用が必要]}、ジャーナリングはまだ実装されていません。

多くの現代のファイルシステムとは異なり、ext3 はスナップショットをネイティブにサポートしていません。スナップショットは、任意の時点でファイルシステムの状態をすばやくキャプチャする機能です。代わりに、Linux LVMが提供する、スペース効率の低いボリュームレベルのスナップショットに依存しています。Next3ファイルシステムは、スナップショットのサポートを提供しながら、ext3 オンディスクフォーマットとの互換性を維持している ext3 の修正バージョンです。[ ^31]

ext3 はジャーナルへの書き込み時にチェックサム計算を行いません。追加キャッシュを備えたストレージデバイスでは、マウントオプションとして ( /etc/fstabで)バリア=1が有効になっていない場合、およびハードウェアが順序どおりに書き込みキャッシュを行っていない場合、クラッシュ時にファイルシステムが破損するリスクがあります。^{[32] [33] [34]}これは、書き込みキャッシュを備えたストレージデバイスが、データが (揮発性) キャッシュに書き込まれた場合でも、データが完全に書き込まれたことをシステムに報告するためです。

ハードディスクへの書き込みが順序どおりに行われない場合 (最近のハードディスクは書き込み速度を緩和するために書き込みをキャッシュするため)、他の関連ブロックが書き込まれる前にトランザクションのコミット ブロックが書き込まれる可能性があります。他のブロックが書き込まれる前に停電や回復不能なクラッシュが発生した場合は、システムを再起動する必要があります。再起動すると、ファイル システムは通常どおりログを再生し、「勝者」(コミット ブロックを持つトランザクション。上記の無効なトランザクションは、たまたま有効なコミット ブロックでタグ付けされていました) を再生します。上記の未完了のディスク書き込みは、破損したジャーナル データを使用して続行されます。したがって、ファイル システムは、ジャーナルを再生するときに、破損したデータで通常のデータを誤って上書きします。チェックサムが使用されていた場合 (「偽の勝者」トランザクションのブロックに相互チェックサムがタグ付けされていた場合)、ファイル システムはより適切に認識し、破損したデータをディスクに再生しなかった可能性があります。ジャーナル チェックサムは ext4 に追加されました。^[35]

デバイスマッパーインターフェースを経由するファイルシステム（ソフトウェアRAIDおよびLVM実装を含む）はバリアをサポートしていない可能性があり、そのマウントオプションが使用されると警告が発行されます。^{[36] [37]}また、バリアが機能するために必要な書き込みキャッシュフラッシュ拡張を適切に実装していないディスクもあり、同様の警告が発生します。^[38]data=journalバリアがサポートされていないか実用的でないこれらの状況では、ディスクの書き込みキャッシュをオフにしてマウントオプションを使用することで、信頼性の高い書き込み順序付けが可能になります。 ^[32]バリアが使用可能な場合でも、ディスクの書き込みキャッシュをオフにする必要がある場合があります。

データベースなどのアプリケーションは、保留中の書き込みをディスクにフラッシュするためにfsync()を呼び出すことを想定していますが、バリア実装は、その呼び出しに応答してドライブの書き込みキャッシュを常にクリアするとは限りません。 ^[39]また、ドライブ障害などのイベント中のエラー処理に関連するバリア実装に関する潜在的な問題もあります。^[40]また、一部の仮想化テクノロジでは、ゲストオペレーティングシステムから基礎となるデバイス (ファイル、ボリューム、ディスク) に fsync コマンドまたはフラッシュコマンドが適切に転送されない場合があることも知られています。^{[41]同様に、一部のハードディスクまたはコントローラーは、キャッシュフラッシュを誤って実装しているかまったく実装していませんが、それでもサポートされていることを宣伝し、使用時にエラーを返しません。 [42]} fsync と書き込みキャッシュの処理を誤って処理する方法は非常に多くあるため、個々のコンポーネントの信頼性がどれほど高いと考えられていても、明示的にテストされない限りキャッシュフラッシュは機能しないと想定するのが安全です。

Ext3はファイルヘッダーの4バイトを使用して日付をUnix時間として保存します。32ビットでは、2038年1月18日以降もファイル処理を継続するのに十分な余裕がありません。これが2038年問題です。^[43]

2006年6月28日、ext3の主任開発者であるセオドア・ツォ^[44]は、ext4と呼ばれる強化版を発表しました。2008年10月11日、ext4を安定コードとしてマークするパッチがLinux 2.6.28ソースコードリポジトリにマージされ、開発フェーズの終了が示され、その採用が推奨されました。2008年にツォは、ext4はext3よりもはるかに高速であるなどの機能が改善されているものの、大きな進歩ではなく、古い技術を使用しており、一時的なものであると述べました。ツォは、Btrfsの方が「スケーラビリティ、信頼性、管理のしやすさが改善されている」ため、より良い方向性であると考えています。^{[45] Btrfsには、「} reiser3 / 4と同じ設計アイデアがいくつか」あります。^[46]

• ファイルシステムのリスト
• ファイルシステムの比較
• 拡張ファイル属性
• Ext2Fsd
• Next3、スナップショットを作成するext3の修正版

• 「Linux ext3 FAQ」。2004-10-14現在。
• ext3 の紹介 – IBM developerWorks 高度なファイルシステム実装ガイド、パート 7
• Paragon ExtBrowser 無料 ext2/ext3 Windows ドライバー
• Windows 用 Ext2 ファイル システム Windows 2000/XP/2003/VISTA/2008 用 GPL ext2/ext3 ファイル システム ドライバー (オープンソース、読み取りと書き込みをサポート、大容量ディスクにアクセスするために最大 256 バイトの inode をサポート)
• Ext2 インストール可能ファイル システム (Windows 用) MS Windows NT4.0/2000/XP/Vista/7/8/8.1/Server 2003/2008/2008 R2/2012/2012 R2 用の ext2/ext3 ファイル システム ドライバー (フリーウェア、クローズド ソース、読み取りと書き込みをサポート、大容量ディスクにアクセスするために最大 256 バイトの inode をサポート)
• MS Windows NT/2000/XP 用の EXT2 IFS ext2/ext3 ファイル システム ドライバー (読み取り専用) (オープンソース)、Web アーカイブの最新バージョン
• Explore2fs MS Windows で ext2/ext3 ファイルシステムにアクセスするためのエクスプローラのような GUI ツール
• 「Ext2read」は、エクステントと LVM2 をサポートする ext2/ext3/ext4 ファイルを読み取り/コピーする Windows アプリケーションです。
• UFS Explorer Standard Recovery バージョン 4 Ext2/Ext3 ファイル システム用の商用データ復旧およびファイル復元ソフトウェア。
• ext2/ext3 サイズ変更ツール
• 2000 年 7 月 20 日のオタワ Linux シンポジウムでの Stephen Tweedie 博士による EXT3 ジャーナリング ファイルシステムに関するプレゼンテーション
• 最先端技術: Ext3 ファイルシステムの現状 2010 年 12 月 31 日にWayback Machineにアーカイブされました。著者: Mingming Cao、Theodore Y. Ts'o、Badari Pulavarty、Suparna Bhattacharya、IBM Linux Technology Center、2005 年
• チュートリアル – EXT3 のサイズ制限の決定
• fuse-ext2 FUSE用のオープンソース ext2/ext3 ファイル システム ドライバー。( Mac OS X 10.4 以降 ( Universal Binary ) をサポート、MacFuse を使用)
• CROSSMETA の Ext2/Ext4 およびその他の FS の Windows ポート
• Red Hat Enterprise Linux、[1]第22章 書き込みバリア。
• 2038 年の Linux クロックポカリプスが迫っているが、「真剣な計画」はない