「Ext4」の版間の差分

2025年4月27日 (日) 00:24時点における最新版

Ext4 は Linux で一番よく使われているファイルシステム、Ext3 の発展版です。多くの点で、Ext3 から Ext4 になって Ext2 から Ext3 に進んだときよりも大きな改善がされています。Ext3 では Ext2 にジャーナリングを追加したのがほとんどでしたが、Ext4 ではファイルデータを保存するファイルシステムの重要なデータ構造にメスが入っています。その結果、改良された設計、優れたパフォーマンス、信頼性、機能性を備えたファイルシステムが誕生しました (ソース: Ext4 - Linux Kernel Newbies)

1 新しく ext4 ファイルシステムを作成
- 1.1 Bytes-per-inode 比率
- 1.2 予約ブロック
2 ext2/ext3 から ext4 に移行
- 2.1 ext2/ext3 パーティションを変換せずに ext4 としてマウント
  - 2.1.1 理由
  - 2.1.2 方法
- 2.2 ext2/ext3 パーティションを ext4 に変換
  - 2.2.1 理由
  - 2.2.2 方法
3 パフォーマンスの向上
4 ヒントとテクニック
5 参照

新しく ext4 ファイルシステムを作成

e2fsprogs をインストールします。

パーティションをフォーマットするには次を実行:

# mkfs.ext4 /dev/partition

ヒント:

オプションについては mke2fs(8) の man ページを見て下さい。/etc/mke2fs.conf を編集すればデフォルトのオプションを見たり設定できます。
サポートされている場合は、メタデータチェックサムを有効にすることをお勧めします。

Bytes-per-inode 比率

mke2fs はひとつの inode に対してディスク上に bytes-per-inode バイト分の領域を作成します。bytes-per-inode 比率を大きくすることで、作成される inode は少なくなります。詳しくは mke2fs(8) を参照。

新しいファイルやディレクトリ、シンボリックリンクなどを作成するとき inode が最低でもひとつは必要です。inode の数が少なすぎると、たとえディスクに空き容量があったとしてもファイルシステムにファイルを作成できなくなります。

ファイルシステムを作成した後に bytes-per-inode 比率や inode の数を変更することはできないため、ファイルが作成できなくなってしまわないように mkfs.ext4 はデフォルトでは比率を低くして inode に対して16384バイト (16Kb) を割り当てます。

しかしながら、1GB 以上のファイルが多数存在してファイルの平均容量がメガバイト級になるような使い方をしているパーティションの場合、inode の数が多すぎてファイルの作成では inode の限界に絶対に達しないということになります。

未使用の inode にも256バイト取られるのでディスク領域の無駄使いです (256バイトという数字は /etc/mke2fs.conf で設定されていますが変更してはいけません) 256バイトでも数百万の inode に換算するとギガバイト単位で容量を無駄にしていることになります。

df と df -i を実行したときの {I}Use% の値を比較することでどれくらい無駄になっているのか確認できます:

$ df -h /home

Filesystem              Size    Used   Avail  Use%   Mounted on
/dev/mapper/lvm-home    115G    56G    59G    49%    /home

$ df -hi /home

Filesystem              Inodes  IUsed  IFree  IUse%  Mounted on
/dev/mapper/lvm-home    1.8M    1.1K   1.8M   1%     /home

bytes-per-inode 比率を変更するには、-T usage-type オプションを使用します。/etc/mke2fs.conf で定義されたタイプを使用してファイルシステムの利用方法を指定できます。largefile や largefile4 タイプは inode に対してそれぞれ 1 MiB と 4 MiB という大きな容量を割り当てます。以下のように使うことができます:

# mkfs.ext4 -T largefile /dev/device

-i オプションを使って bytes-per-inode 比率を直接設定することもできます。例えば -i 2097152 なら 2 MiB、-i 6291456 なら 6 MiB になります。

ヒント: 逆に、メールやニュースグループのアイテムなどで小さなファイルを何百万も保存するような使い方をする場合、news (ひとつの inode に4096バイトを割り当て) や small (inode 自体のサイズやブロックサイズも小さくする) などのタイプを使うこともできます。

警告: シンボリックリンクを大量に使用する場合は、bytes-per-inode 比率を低くして inode の数量は大きくしてください。シンボリックリンクを作成しても容量は取られませんが inode はひとつ消費されるので、ファイルシステムの inode をあっという間に使い切ってしまう可能性があります。

予約ブロック

デフォルトでは、ファイルシステムの 5% はフラグメントが起こらないように root ユーザー用に予約されます。非特権のプロセスがファイルシステムに書き込めなくなってからも root が使用しているデーモンは正しく動作し続けることができます (詳しくは mke2fs(8) を参照)。

最近の大容量ディスクでは、パーティションを長期アーカイブとして使用したり、システム運用に重要でない場合(/homeなど)必要以上に大きな値を設定します。予約ブロックに関する ext4 開発者の Ted Ts'o の意見はこのメールを、このトピックに関する一般的な背景はこのスーパーユーザの回答を参照してください。

パーティションが以下の条件を満たしているならば、ディスク容量を増やすために予約ブロックの割合を減らしても大抵は問題ありません:

パーティションがとても大きい (例えば 50GB 以上)
長期保存用のアーカイブとして使っている、頻繁にファイルを作成したり削除することがない。

ext4 関連のユーティリティを使うときに -m オプションで予約ブロックの割合を指定できます。

ファイルシステムの作成時に予約ブロックを全く作成しないようにするには:

# mkfs.ext4 -m 0 /dev/device

パーティションの予約ブロックの割合を 1% に設定するには:

# tune2fs -m 1 /dev/device

予約ブロック数をギガバイト単位の絶対サイズに設定する場合は、-r を使用します。

# tune2fs -r $((ngigs * 1024**3 / blocksize)) /dev/device

blocksize はファイルシステムのブロックサイズをバイト単位で指定します。これはほとんどの場合 4096 ですが、念のため確認することができます。

# tune2fs -l /dev/device | egrep '^Block size:'

Block size:               4096

$(()) 構文は、数式展開のための構文です。この構文は bash と zsh では動作しますが、fish では動作しません。fish では、このような構文になります。

# tune2fs -r (math 'ngigs * 1024^3 / blocksize') /dev/device

これらのコマンドは、現在マウントされているファイルシステムに適用することができ、変更は即座に反映されます。デバイス名は findmnt(8) で調べることができます。

# tune2fs -m 1 "$(findmnt -no SOURCE /the/mount/point)"

現在の予約ブロック数を問い合わせる場合。

# tune2fs -l /dev/mapper/proxima-root | egrep '^Reserved block count:'

Reserved block count:     2975334

これはブロック数なので、これにファイルシステムのブロックサイズを掛けて、バイト数やギガバイト数を得る必要があります。2975334 * 4096 / 1024**3 = 11.34 GiB です。

ext2/ext3 から ext4 に移行

ext2/ext3 パーティションを変換せずに ext4 としてマウント

理由

ext4 を完全に変換する案と ext2/ext3 をそのまま使用する案の折衷案として、既存の ext2/ext3 パーティションを ext4 としてマウントする方法があります。

利点:

互換性 (ext2/ext3 としてファイルシステムをマウントできます) – ext4 のサポートがないオペレーティングシステムからもファイルシステムを読み込むことが可能です (例: Windows の ext2/ext3 ドライバー)
パフォーマンスが向上 (ext4 パーティションに完全に変換するのよりは劣ります) – 詳しくは [1] や [2] を見てください。

欠点:

ext4 の機能を全て活用することはできません (マルチブロックアロケーションや遅延アロケーションなどのディスクフォーマットに変更を与える機能は使えません)

ノート: ext4 が比較的新しいファイルシステムということ以外に (このこと自体をリスクと考えることもできます)、この方法を使用することで不利益になることは特にありません。

方法

/etc/fstab を編集して ext4 としてマウントしたいパーティションの 'type' を ext2/ext3 から ext4 に変更してください。
変更したパーティションを再マウントします。

ext2/ext3 パーティションを ext4 に変換

理由

ext4 の能力を活かすには、非可逆の変換をする必要があります。

利点:

パフォーマンスの向上と新機能 – 詳しくは [3] や [4] を見てください。

欠点:

/boot パーティションなど、静的なファイルしか存在しない場合、新機能を使うメリットはありません。さらに、ジャーナリングによって性能がむしろ落ちる可能性もあります。
一方通行 (ext4 パーティションを ext2/ext3 に'ダウングレード'することはできません) ただしエクステントなどのオプションを有効にしなければ後方互換性を確保できます。

方法

以下の手順はカーネルドキュメントとフォーラムスレッドから引用しています。

警告:

システムのルートパーティションを変換する場合、再起動時にフォールバックの initramfs が使えるようになっていることを確認してください。また、変換する前に /etc/mkinitcpio.conf の MODULES 行に ext4 を追加して mkinitcpio -p linux でデフォルトの initramfs を再作成してください。
分割している /boot パーティションを変換する場合、ブートローダーが ext4 からの起動に対応していることを確認してください。

バックアップを行なって下さい。ext4 に変換する ext3 パーティションに存在するデータを全てバックアップします。特に / (root) パーティションをバックアップする場合は、Clonezilla が役に立ちます。
/etc/fstab を編集して ext4 に変換するパーティションの 'type' を ext3 から ext4 に変換してください。
(必要であれば) ライブメディアを起動します。e2fsprogs で変換を行う際はドライブがマウントされていない状態になっている必要があります。ドライブの root (/) パーティションを変換するときは、他のライブメディアから起動して変換するのが一番簡単です。
パーティションがマウントされていないことを確認してください
ext2 パーティションを変換する場合、まずは tune2fs -j /dev/sdxX を root で実行してジャーナルを追加して ext3 パーティションに変換してください。
tune2fs -O extent,uninit_bg,dir_index /dev/sdxX を root で実行 (/dev/sdxX は変換するパーティションのパスに置き換えて下さい、例: /dev/sda1)。ext4 に変換されます (不可逆です)
root で fsck -f /dev/sdxX を実行。
- ファイルシステムのチェックを実行しないとファイルシステムを読み込めなくなります。fsck の実行は必須です。グループ記述子のチェックサムエラーが発見されます。これは仕様通りの動作です。-f オプションはファイルシステムに問題がない場合でも強制的にチェックを実行します。-p オプションを使用して自動修復させることもできます (オプションを使用しない場合、エラーに対して入力を求められます)
推奨: パーティションをマウントして e4defrag -c -v /dev/sdxX を実行。
- ファイルシステムが ext4 に変換されても、変換前に書き込まれたファイルは ext4 のエクステントオプションを利用することができません。エクステントオプションは巨大なファイルの操作を高速化しフラグメンテーションを減らしてファイルシステムのチェック時間を短縮します。ext4 を活用するには、全てのファイルをディスクに再書き込みする必要があります。e4defrag を使うことで問題を解決できます。
Arch Linux を再起動してください。

パフォーマンスの向上

アクセス時間の更新を無効にする

ext4ファイルシステムは、ファイルが最後にアクセスされた時刻に関する情報を記録しますが、これには記録に伴うコストがあります。noatime や関連するオプションについては、fstab#atime オプションを参照してください。

コミット間隔の増加

commit オプションで長い時間遅延を提供することにより、データとメタデータの同期間隔を増やすことができます。

デフォルトの5秒は、電源が失われた場合、最新の5秒の作業が失われることを意味します。 5秒ごとにすべてのデータ/ジャーナルを物理メディアに完全に同期します。ただし、ジャーナリングのおかげで、ファイルシステムが損傷することはありません。次の fstab は、 commit の使用法を示しています。

/etc/fstab

/dev/sda5    /    ext4    defaults,commit=60    0    1

バリアとパフォーマンス

警告: バリアを無効化すると、電源が失われたときにキャッシュが正しく書き込まれるか保証がされなくなります。これによってファイルシステムの破壊やデータ損失が発生する場合があります。

Ext4 はデフォルトで書き込みバリアを有効にします。これにより、書き込みキャッシュの電源が失われた場合でも、ファイルシステムのメタデータがディスク上に正しく書き込まれ、順序付けされることが保証されます。これには、特に fsync を頻繁に使用するアプリケーションや、小さなファイルを多数作成および削除するアプリケーションの場合、パフォーマンスにコストが伴います。何らかの方法でバッテリーバックアップが行われている書き込みキャッシュを持つディスクの場合、バリアを無効にするとパフォーマンスが安全に向上する可能性があります。

バリアをオフにしたいときは /etc/fstab の変更したいファイルシステムに barrier=0 オプションを追加してください。例:

/etc/fstab

/dev/sda5    /    ext4    defaults,barrier=0    0    1

ジャーナリングの無効化

警告: ジャーナリングなしでファイルシステムを使用すると、停電やカーネルのロックアップなどの突然のマウント解除の場合にデータが失われる可能性があります。

ext4 を使用してジャーナルを無効にするには、マウントされていないディスクで次のコマンドを使用します。

# tune2fs -O "^has_journal" /dev/sdXN

ジャーナルを使用してパフォーマンスを最適化する

Fast commits for ext4 の記事のイントロダクションは、マウントオプション data=journal や data=writeback が、デフォルトの data=ordered 動作モードと比較して、どのように全体的な ext4 のパフォーマンスを高速化するかを簡潔にまとめています。さらに、ジャーナリング自体は、journal_async_commit マウントオプションを追加することで高速化できます。

ノート: journal_async_commit マウントオプションは、デフォルトのマウントオプションである data=ordered と一緒に使うと動作しません。なので、明示的に ext4_device を別のモードでマウントしてください。ext4(5) § data= を見てください。

さらに別のオプションとして、新しいジャーナルフォーマットを使用する方法があります。詳細は #fast_commit を有効化を参照してください。

外部ジャーナルデバイス

デフォルト以外の data= オプションを使用している場合、専用のジャーナルデバイスを使用することで、ファイル操作が高速化される場合もあります。例えば、データには比較的遅いデバイスを使用し、ジャーナルにはより高速だが小容量の別デバイスを使用する場合などです。別のジャーナルデバイスを設定するには:

# mke2fs -O journal_dev /dev/journal_device

ext4_device のジャーナルとして journal_device を割り当てるには、次を使用してください:

# tune2fs -J device=/dev/journal_device /dev/ext4_device

ext4_device に新しいファイルシステムを作成したい場合は、tune2fs の代わりに mkfs.ext4 を使用してください。

journal_device を ext4_device の依存関係として追加するには、/etc/fstab で x-systemd.requires マウントオプションを使用します:

/etc/fstab

/dev/ext4_device    /    ext4    defaults,x-systemd.requires=/dev/journal_device    0    1

これにより、journal_device にセットアップ (例:暗号化) が必要な場合でも問題を防ぐことができます。

ノート: UUID とジャーナルデバイスの devnum の両方が ext4 ファイルシステムに保存されます。ジャーナルデバイスの読み込み時には devnum のみが使用されるため、ディスクの並び順が変更されると問題が発生します。devnum が間違ったデバイスを指している場合、Linux はファイルシステムのマウントを拒否しますが、以下の回避策が役立つかもしれません:

パスを使用してジャーナルのロードを強制する journal_path マウントオプションを使い、保存された devnum を無視する:

/etc/fstab

/dev/ext4_device    /    ext4    defaults,x-systemd.requires=/dev/journal_device,journal_path=/dev/journal_device    0    1

e2fsck は UUID を使ってジャーナルデバイスを検索し、ずれていた場合には保存された devnum を修正します。ただし、これを破損とみなして不要なフルファイルシステムスキャンをトリガーしてしまいます([5] を参照)これを e2fsck の設定ファイルで無効化できます:

/etc/e2fsck.conf

[problems]
# PR_0_EXTERNAL_JOURNAL_HINT: Superblock hint for external superblock should be xxxx
0x000033 = {
    # Tell e2fsck that if this problem is encountered, it can be fixed but should
    # not be considered corruption, the filesystem should still be marked clean.
    not_a_fix = true
}

ヒントとテクニック

ファイルベースの暗号化を使用する

Linux 4.1 以降、ext4 はファイル暗号化をネイティブにサポートしています。 fscrypt の記事を参照してください。暗号化はディレクトリレベルで適用され、ディレクトリごとに異なる暗号化キーを使用できます。これは、ブロックデバイスレベルの暗号化である dm-crypt と、スタック暗号化ファイルシステムである eCryptfs の両方とは異なります。

メタデータチェックサムを有効化する

ファイルシステムが e2fsprogs で作成されている場合。1.43 (2016) 以降では、メタデータチェックサムがデフォルトで有効になっています。既存のファイルシステムを変換して、メタデータチェックサムのサポートを有効にすることができます。

CPU が SSE 4.2 をサポートしている場合、crc32c_intel が有効であることを確認してください。ハードウェアアクセラレーションによる CRC32C アルゴリズム [6] を有効にするためにカーネルモジュールがロードされています。もしそうでなければ、代わりに crc32c_generic モジュールをロードしてください。

メタデータチェックサムの詳細については、ext4 wiki を参照してください。

ヒント: dumpe2fs を使用して、ファイルシステムで有効になっている機能を確認します。

# dumpe2fs -h /dev/path/to/disk

ノート: ファイルシステムをマウントしないでください。

まず、e2fsck を使用してパーティションをチェックし、最適化する必要があります。

# e2fsck -Df /dev/path/to/disk

ファイルシステムを64ビットに変換します。

# resize2fs -b /dev/path/to/disk

最後に、チェックサムサポートを有効にします。

# tune2fs -O metadata_csum /dev/path/to/disk

検証します:

# dumpe2fs -h /dev/path/to/disk | grep features:

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

LVM を使用する場合のメンテナンス

e2scrub ツールは、ext4ファイルシステムのメタデータをチェックするためのツールで、特に LVM (Logical Volume Manager) の論理ボリュームで使用されている場合に適用されます。このチェックを行うには、ボリュームグループに256MiBの未割り当てスペースが必要です。これは、ツールがチェック用にスナップショットを作成するためです。

e2scrub(8) マニュアルによると、このツールはエラーを修復するものではなく、エラーを報告し、次回のマウント前に e2fsck(e2fsck(8) を参照)の実行が必要であることをファイルシステムにマークします。

このチェックは自動化可能で、例えば、パッケージに含まれる e2scrub_all.timer ユニットを有効化することで設定できます。

なお、必要な256MiBの未割り当てスペースが不足している場合は、LVM#論理ボリュームとファイルシステムのサイズを一度に変更するを参照してください。

fast_commit を有効化

ext4の "fast commits" 機能は、新しい軽量なジャーナリング方式を導入します。この機能は、ext4 ファイルシステムのパフォーマンスを大幅に向上させることが期待されています。[7]

新しいファイルシステムでこの機能を有効にするには、fast_commit を -O ファイルシステムオプション引数に含めます。

既存のファイルシステムでこの機能を有効にするには、次のコマンドを実行します:

# tune2fs -O fast_commit /dev/drivepartition

現在の構成または変更を確認するには:

# tune2fs -l /dev/drivepartition | grep features

既存のファイルシステムでこの機能を無効にするには、次のコマンドを実行します:

# tune2fs -O '^fast_commit' /dev/drivepartition

大文字と小文字を区別しないモードを有効にする