Ext4の機能

この記事は、KernelNewbies に関する記事の一部の翻訳であり、Ext4ファイルシステムの機能について説明しています。 Ext4の使用に関する記事の最後のセクションは、すでにHabréで公開されています。



Ext4は、Linuxで最も人気のあるファイルシステムであるExt3の進化版です。 多くの面で、Ext4はExt3がExt2と比較されたよりもExt3に比べて大幅に改善されています。 Ext2に対するExt3の最も重要な改善はジャーナリングでしたが、Ext4はファイルデータを保存するために設計されたものなどの重要なデータ構造への変更を伴います。



これにより、より高度な設計、より生産的で安定したファイルシステム、および広範な機能セットを備えたファイルシステムを作成できました。

1.互換性

Ext3などの既存のファイルシステムは、読み取り専用モードでコマンドのペアを起動するという簡単な手順でExt4に変換できます。 つまり、再フォーマットすることなく、OSとプログラムを再インストールすることなく、生産性と容量を向上させ、既存のファイルシステムの機能を向上させることができます。 本番システムでExt4の利点が必要な場合は、ファイルシステムをアップグレードすることもできます。 この手順は安全であり、データを危険にさらすことはありません（もちろん、この場合、重要なデータをバックアップすることをお勧めします。ただし、ファイルシステムを変更しない場合でもこれを行う必要があります）。



Ext4は新しいデータに対してのみ新しい構造を使用しますが、古い構造は変更されません。 必要に応じて、それらを読み取り、変更できます。 つまり、ファイルシステムをExt4に変更すると、Ext3を返すことができなくなります。



また、新しいデータ形式を使用せずにExt3ファイルシステムをExt4としてマウントすることもできます。これにより、Ext3として再びマウントできるようになります。 この場合、もちろん、Ext4の多くの利点を活用することはできません。

2.より大きなファイルとファイルシステムのサイズ

現在まで、Ext3ファイルシステムの最大サイズは16テラバイトであり、ファイルサイズは2テラバイトに制限されています。 Ext4は48ビットのブロックアドレッシングを追加します。つまり、このファイルシステムの最大サイズは1エクサバイトであり、ファイルのサイズは最大16テラバイトになります。 1 EB（エクサバイト）= 1,048,576 TB（テラバイト）、1 EB = 1024 PB（ペタバイト）、1 PB = 1024 TB、1 TB = 1024 GB。 なぜ64ビットではなく48ビットなのですか？ Ext4を完全に64ビットにするために削除しなければならない多くの制限があり、Ext4にはそのようなタスクがありませんでした。 Ext4のデータ構造は、必要な変更を考慮して設計されているため、将来のある日、Ext4での64ビットサポートが登場します。 その間、1エクサバイトで満足しなければなりません。



注：この記事の執筆時点で16テラバイトを超えるファイルシステムを作成するためのコードは、e2fsprogsの安定リリースには含まれていません。 将来的には追加されます。

3.サブディレクトリのスケーラビリティ

現在、1つのExt3ディレクトリに32,000を超えるサブディレクトリを含めることはできません。 Ext4はこの制限を取り除き、無制限の数のサブディレクトリを作成できます。

4.エクステント

Ext3などの従来のUnix由来のファイルシステムは、間接ブロックマッピングスキームを使用して、ファイルデータの格納を担当する各ブロックを追跡します。 対応ファイルのマップには個々のブロックごとに1つのレコードが含まれるため、このアプローチは大きなファイル、特にそのようなファイルを削除および切り捨てる場合には効果的ではありません。 大きなファイルには多くのブロックがあり、それらの対応マップは大きく、それらはゆっくりと処理されます。



現代のファイルシステムは、いわゆるエクステントに基づいて異なるアプローチを取ります。 エクステントは、基本的に一連の連続した物理ブロックです。 彼は、「このデータは次のnブロックにある」と言っています。 たとえば、100メガバイトのファイルは、25600の4キロバイトブロックに分割する代わりに、同じサイズの単一のエクステントに格納でき、間接マッピングでアドレス指定されます。 巨大なファイルはいくつかのエクステントに分割できます。



エクステントは、データの継続的な配置に寄与するため、パフォーマンスと断片化を改善できます。

5.マルチブロック分散

Ext3が新しいデータをディスクに書き込む必要がある場合、特別なブロック割り当てメカニズムがこれに使用する空きブロックを決定します。 問題は、Ext3でこのメカニズムが1ブロック（4キロバイト）だけを一度に配布することです。 つまり、前述の100メガバイトのデータを記録する場合、25600回の分散メカニズムを使用する必要があります（約100メガバイトについて話している！）。 これは非効率的であるだけでなく、対応するメカニズムが実際に書き込まれるデータ量についての手がかりを持たず、単一のブロックについてのみ知っているため、配布ポリシーの最適化も許可しません。



Ext4はマルチブロックアロケーター（mballoc）メカニズムを使用します。これにより、1回の呼び出しで任意の数のブロックを分散し、大きなオーバーヘッドを回避できます。 このため、生産性は大幅に向上します。これは、エクステントを使用した遅延配信（以下を参照）で特に顕著です。 この機能はデータ形式には影響しません。



Ext4では、ブロック割り当てメカニズムとiノードが、このドキュメントで詳細に説明されている他の改善を受け取ったことにも注意できます 。

6.遅延配布

遅延配布は、データ形式に影響を与えず、XFS、ZFS、btrfs、Reiser 4などの最新のファイルシステムに存在するパフォーマンスを改善する方法です。



この方法の本質は、ブロックの割り当てを可能な限り遅らせることです（従来のファイルシステム（Ext3、reiser3など）で使用されているアプローチとは対照的に）。できるだけ早くブロックをすぐに配布します。 たとえば、プロセスがwrite（）を呼び出して書き込む場合、ファイルシステムは、データがまだディスクに書き込まれていないが、しばらくキャッシュにある場合でも、すぐに書き込み用のブロックを割り当てます。 たとえば、このアプローチの欠点は、プロセスが成長中のファイルに継続的に書き込みを行う場合、write（）の連続呼び出しによりデータブロックが常に割り当てられ、ファイルがさらに成長するかどうかがわからないことです。



遅延分散を使用する場合、書き込み（）が呼び出されたときにブロックはすぐには割り当てられません。 代わりに、ファイルがキャッシュからディスクに書き込まれるまで、配布は遅延します。 これにより、メカニズムは配布プロセスを最適化できます。 最大のゲインは、前述の2つの機能-エクステントとマルチブロック分散を使用することで得られます。これは、mballocを使用して分散されるエクステントの形式でディスクに最終ファイルが書き込まれる場合が多いためです。 これにより、パフォーマンスが大幅に向上し、場合によってはデータの断片化が大幅に減少します。

7.高速fsck

Fsckは、特に最初の段階では非常に遅い操作であり、ファイルシステム内のすべてのiノードをチェックします。



Ext4では、各グループのiノードテーブルの後に、未使用のiノードのリストが保存され（信頼性のためのチェックサムが提供されます）、fsckはそのようなiノードをチェックしません。 その結果、スキャン時間が2倍から20倍に短縮されます。これは、使用されるiノードの数に依存します（ http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4を参照）。



未使用のiノードのリストがext4ではなくfsckによってコンパイルされるという事実は、fsckを実行して未使用のiノードのリストを作成する場合、および次のfsckのみがより速く開始する場合に明確に表示されます（Ext3をExt4に変換する場合は、fsckが必要です）。



さらに、fsckアクセラレーションは別の機能「フレキシブルブロックグループ」の影響を受け、他のファイル操作も高速化します。

8.ジャーナルのチェックサム

マガジンはディスクの中で最も頻繁に使用される部分であり、その結果、マガジンを構成するブロックは、機器の故障に特に敏感になります。 さらに、破損したログから回復しようとすると、さらに大規模なデータ破損が発生する可能性があります。 Ext4は、ログデータのチェックサムを計算します。これにより、損傷の事実を判断できます。 これにはもう1つの利点があります：チェックサムのおかげで、Ext3 2フェーズロギングシステムを単一フェーズに変えることができ、場合によってはファイル操作を最大20％スピードアップし、信頼性とパフォーマンスの両方が向上します。



注：パフォーマンスを担当する部分（非同期ログ）は現在デフォルトでオフになっており、信頼性の高い操作を実現できる場合は、次のリリースのいずれかに含まれます。

9.非ロギングモード

ジャーナリングは、ディスクで発生したすべての変更を記録することにより、ファイルシステムの整合性を保証します。 ただし、追加のディスクオーバーヘッドも発生します。 特別な状況では、ジャーナリングとそれが提供する利点が冗長になる場合があります。 Ext4では、ジャーナリングを無効にできるため、パフォーマンスがわずかに向上します 。

10.オンラインでの最適化

この機能はまだ開発中であり、将来のリリースの1つに含まれる予定です。



遅延およびマルチブロックの分散とエクステントはファイルシステムの断片化を減らすのに役立ちますが、それでも時間の経過とともに大きくなる可能性があります。



たとえば、1つのディレクトリに3つのファイルを作成し、それらが次々とディスクに配置されます。 次に、ある日、2番目のファイルを更新することにし、同時にファイルが少し大きくなります。そのため、十分なスペースがありません。 同時に、ファイルの不適合フラグメントを分離して別のディスクの場所に置くか、最初の2つのファイルから離れた別の場所にある大きなディスクのシーケンシャル領域のファイルを選択する以外に解決策はありません。ディレクトリ内のすべてのファイル（たとえば、ファイルマネージャーは画像ファイルのサムネイルを作成します）。



さらに、ファイルシステムは特定の種類の断片化のみを処理でき、たとえば、起動時に必要なファイルをすべて隣り合わせに格納する必要があることを知ることはできません。 この問題を解決するために、Ext4はオンラインでの最適化をサポートします。



また、e4defragユーティリティもあり、個々のファイルとファイルシステム全体の両方を最適化できます。

11. iノードに関連する改善

より大きなiノード、ナノ秒のタイムスタンプ、高速の高度な属性、iノードの冗長性...

• より大きなiノード：Ext3は（-Iパラメーターmkfsを指定することにより）カスタムサイズのiノードをサポートしますが、デフォルトのiノードサイズは128バイトです。 Ext4では、256バイトになります。 これは、いくつかの追加フィールド（ナノ秒のタイムスタンプやiノードバージョンなど）を収容するために必要であり、iノードに残っているスペースは、そこに収まるほど小さい拡張属性を格納するために使用されます。 これにより、このような属性へのアクセスがはるかに高速になり、それらを使用するアプリケーションの生産性が3〜7倍向上します。
• iノード冗長性の本質は、ディレクトリの作成時に複数のiノードを割り当てることであり、将来それらが使用されることを見込んでいます。 このディレクトリに新しく作成されたファイルは予約済みiノードを使用できるため、これによりパフォーマンスが向上します。 したがって、ファイルの作成と削除はより効率的です。
• ナノ秒のタイムスタンプは、変更時間などのiノードフィールドがナノ秒の精度になることを意味します（Ext3では、1秒に相当しました）。

12.持続可能な再配布

この機能は、最新のカーネルバージョンのExt3で既に利用可能であり、それをサポートしていないファイルシステムでglibcによってエミュレートされるため、アプリケーションはディスクスペースを事前に割り当て、ファイルシステムにニーズを報告できます。 次に、必要な数のブロックとデータ構造を割り当てますが、アプリケーションが実際にそれらを書き込むまで空です。



これは、たとえば、P2Pアプリケーションが行うことであり、数時間または数日後にそこにのみ表示されるデータ用のスペースを割り当てます。 ただし、これはファイルシステムレベルで、ユニバーサルAPIを使用して、はるかに効率的に実装されます。



これにはいくつかのアプリケーションがあります：まず、同じアプリケーション（P2Pなど）がゼロでファイルを非効率的に埋めることを防ぐために、必要なブロックがすぐに選択されます。



第二に、断片化を減らすために-ブロックが可能な限り連続的に一度割り当てられるためです。



第三に、重要な操作の実行中にファイルシステムが突然いっぱいになる可能性があるため、アプリケーションに必要なだけのスペースを確保すること。これはリアルタイムアプリケーションにとって特に重要です。



この機能は、libc posix_fallocate（）インターフェイスを介して利用できます。

13.「バリア」のメカニズムはデフォルトで有効になっています

これは、パフォーマンスの低下を犠牲にしてファイルシステムの整合性を保証するオプションです（「mount -o barrier = 0」を使用して無効にできます。パフォーマンスを測定する場合はこれを行うことをお勧めします）。



LWNの記事からの抜粋：「ファイルシステムコードは、コミット[ログ]レコードを作成する前に、すべてのトランザクション情報がログに記録されることを絶対に確認する必要があります。 正しい順序で録音するだけでは十分ではありません。 最新のドライブには大きなキャッシュがあり、パフォーマンスを最適化するために記録順序を変更します。 したがって、ファイルシステムは、コミットレコードを作成する前に、すべてのログデータをメディアに書き込む必要があることをディスクに明示的に通知する必要があります。 最初にコミットレコードが作成された場合、ログが破損している可能性があります。 カーネルのブロッキング入出力システムは、「バリア」（バリア）を使用してこの機会を提供します。 簡単に言えば、「バリア」は、「バリア」がメディアに転送される前に送信されたすべてのブロックまで、それ以降に送信されたブロックの記録を禁止します。 「バリア」を使用すると、ファイルシステムは、ディスク上のすべてがいつでも完全であることを保証できます。