ext4

大規模ファイルシステム ext4 ファイルシステムは、標準の 4 KiB ブロックサイズで最大 1 exbibyte (EiB) サイズのボリュームと最大 16 tebibyte (TiB) サイズの単一ファイルをサポートすることが可能です。 ファイル、ディレクトリ、ファイルシステムの最大サイズ制限は、少なくともファイルシステムのブロックサイズに比例して大きくなり、ARMとPowerPC/Power ISA CPUで利用可能な最大64 KiBブロックサイズまでとなります。 エクステント エクステントは、ext2 や ext3 で使われていた従来のブロックマッピング方式を置き換えるものです。 エクステントは、連続した物理ブロックの範囲であり、ラージファイルのパフォーマンスを向上させ、フラグメンテーションを低減します。 ext4 の 1 つのエクステントは、4 KiB ブロックサイズで最大 128 MiB の連続したスペースをマップできます。 inodeに直接格納されるエクステントは4つまでです。 1つのファイルに4つ以上のエクステントがある場合、残りのエクステントはツリーでインデックス化されます。 後方互換性 ext4 は ext3 および ext2 と後方互換性があり、ext3 および ext2 を ext4 としてマウントすることが可能である。 これは、ext4 の実装の一部の新機能が、新しいブロック割り当てアルゴリズムなど、ディスク上のフォーマットに影響を与えずに ext3 と ext2 でも使用できるため、パフォーマンスがわずかに向上します。ext3 は ext4 と部分的に前方互換性があります。 実際、ext4 は、^extent^flex_bg^huge_file^uninit_bg^dir_nlink^extra_isize など、作成時に特定の新機能を無効にしない限り、ext3 ファイルシステムとしていきなりマウントされることはありません。 持続的な事前割り当て ext4 は、ファイルのためにディスク上のスペースを事前に割り当てることができます。 ほとんどのファイルシステムでこれを行うには、 ファイルを作成するときに 0 を書き込むことになる。 ext4 (および XFS など他のいくつかのファイルシステム) では、Linux カーネルの新しいシステムコールである fallocate() を使用することができる。 割り当てられた領域は保証され、連続である可能性が高い。 この状況は、メディアストリーミングやデータベースへの応用があります。 遅延割り当て ext4 は allocate-on-flush (遅延割り当てとも呼ばれる) と呼ばれるパフォーマンステクニックを使用しています。 つまり、ext4 はデータがディスクにフラッシュされるまでブロックの割り当てを遅らせるのです。 (これに対して、いくつかのファイルシステムは、データがライトキャッシュに入った場合でも、すぐにブロックを割り当てます)。 遅延割り当ては、一度に大量のデータを効果的に割り当てることで、パフォーマンスを向上させ、フラグメンテーションを減少させます。 サブディレクトリの数は無制限 ext4 では、ディレクトリ自体のサイズ制限を除いて、1 つのディレクトリに含まれるサブディレクトリの数は制限されていません。 (ext3 では、1 つのディレクトリは最大 32,000 個のサブディレクトリを持つことができます。) より大きなディレクトリと継続的なパフォーマンスを可能にするために、Linux 2.6.23 以降の ext4 ではデフォルトで HTree インデックス (B-tree の特殊版) を有効にし、2 レベルの HTree インデックスと 4 KiB ブロックサイズに対して 2 GB のディレクトリサイズ制限で、ファイル名の長さに依存して最大約 1000 万〜 1200 万エントリのディレクトリが保存できるようになっています。 Linux 4.12 以降では、largedir 機能により 3 レベルの HTree と 2 GB を超えるディレクトリサイズが有効になり、1 つのディレクトリに約 60 億のエントリを格納できるようになりました。 ジャーナルチェックサム ext4 では、ジャーナルがディスクで最も使用されるファイルの 1 つであるため、信頼性を高めるためにジャーナルにチェックサムを使用しています。 この機能には副次的な効果があり、ジャーナリング中のディスク I/O の待ち時間を安全に回避することができ、パフォーマンスが若干向上します。 ジャーナルチェックサムはウィスコンシン大学の IRON File Systems (特にセクション 6 の “transaction checksums”) という研究論文からヒントを得て、IRON ファイルシステム (元々は Sam Naghshineh が RedHat サミットで提案) によって実行される複合トランザクションの実装内で修正されたものです。 メタデータチェックサム 2012年にリリースされたLinuxカーネル3.5以降 ファイルシステムチェックの高速化 ext4では、未割り当てのブロックグループとinodeテーブルのセクションがそのようにマークされます。 これにより、e2fsck はそれらを完全にスキップすることができ、ファイルシステムのチェックにかかる時間を大幅に短縮することができます。 Linux 2.6.24 では、この機能が実装されています。

fsck time dependence on inode count (ext3 vs. ext4)

Multiblock allocator ext3 がファイルに追記するとき、各ブロックに対して一度、ブロックアロケータを呼び出します。 そのため、複数の書き込み者が同時に存在する場合、ファイルがディスク上で断片化しやすくなります。 しかし、ext4では遅延割り当てを行うことで、データをバッファリングし、ブロックのグループを割り当てることができる。 その結果、マルチブロック・アロケータは、ディスク上でファイルを連続的に割り当てるためのより良い選択をすることができます。 マルチブロックアロケータは、ファイルが O_DIRECT モードで開かれる場合にも使用できます。 この機能は、ディスク・フォーマットには影響を与えません。 タイムスタンプの改良 コンピュータが一般に高速化し、Linux がミッションクリティカルな用途に使われるようになると、秒ベースのタイムスタンプでは粒度が足りなくなります。 そこでext4では、ナノ秒単位でタイムスタンプを提供する。 さらに、拡張タイムスタンプフィールドの2ビットがタイムスタンプの秒フィールドの最上位ビットに追加され、2038年問題をさらに408年先送りにしている。 しかし、Theodore Ts’o が指摘するように、inode に追加の作成日フィールドを追加するのは簡単ですが(したがって、ext4 でこれらのタイムスタンプのサポートを技術的に可能にする)、stat() などの必要なシステムコール(おそらく新しいバージョンが必要)やそれに依存する各種ライブラリ(たとえば glibc)を修正または追加することはより困難です。 これらの変更には、多くのプロジェクトの調整が必要です。 そのため、ext4によって保存される作成日は、現在Linux上のユーザプログラムがstatx()APIを介してのみ利用可能です。 プロジェクトクォータ 2016年1月8日のLinuxカーネル4.4で、プロジェクトクォータのサポートが追加されました。 この機能により、特定のプロジェクトIDにディスククォータ制限を割り当てることができます。 ファイルのプロジェクトIDは、各ファイルに格納されている32ビットの番号で、プロジェクトIDが割り当てられた親ディレクトリの下に作成されたすべてのファイルとサブディレクトリに継承されます。 これにより、UIDとGIDに依存するユーザーとプロジェクトクォータのような、ファイルのアクセス権限から独立して、特定のサブディレクトリツリーにクォータ制限を割り当てることができます。 これはディレクトリクォータと似ていますが、主な違いは、同じプロジェクトIDを複数のトップレベルディレクトリに割り当てることができ、厳密には階層構造になっていないことです。 透過的暗号化 2015年6月のLinuxカーネル4.1で透過的暗号化のサポートが追加されました。 遅延初期化 lazyinit機能は、バックグラウンドでinodeテーブルをクリーニングし、新規ext4ファイルシステム作成時の初期化を高速化することができる。 Linuxカーネルバージョン2.6.37で2010年から利用可能です。 ライトバリア ext4 はデフォルトでライトバリアを有効にします。 これは、書き込みキャッシュの電力が失われた場合でも、ファイルシステムのメタデータがディスク上に正しく書き込まれ、順序付けされることを保証するものです。 これは、特に fsync を多用するアプリケーションや、多くの小さなファイルを作成・削除するアプリケーションにとっては、パフォーマンス上の代償となるものです。 バッテリバックアップされた書き込みキャッシュを持つディスクでは、 バリアを無効にする (オプション ‘barrier=0’) ことで、安全にパフォーマンスを向上させることができる。

コメントを残す

メールアドレスが公開されることはありません。