Ext4

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

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

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

# 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) を参照)。

最近の大容量ディスクでは、パーティションを長期保存用のアーカイブとして使う場合、5%は必要以上に大きい値となります。ext4 の開発者である Ted Ts'o による予約ブロックについての議論はこのメールを見てください。

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

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

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

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

# mkfs.ext4 -m 0 /dev/device

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

# tune2fs -m 1 /dev/device

findmnt(8) を使うことでデバイスの名前を確認できます:

$ findmnt /the/mount/point

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 を再起動してください。

パフォーマンスの向上

E4rat

E4rat は ext4 ファイルシステム用に作られたプリロードアプリケーションです。E4rat は起動時に開かれるファイルを記録して、アクセス時間が短縮されるようにパーティションにおけるファイルの配置を最適化します。そして起動時の初期段階でファイルを先読みします。E4rat は SSD を使っている場合は効果がありません。SSD のアクセス時間はハードディスクと比べると無視できるほどしかないためです。

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

ext4 ファイルシステムは、ファイルが最後にアクセスされた日時に関する情報を記録し、その記録にはコストがかかります。 noatime オプションを使用すると、ファイルシステムのアクセスタイムスタンプは更新されません。

/etc/fstab

/dev/sda5    /    ext4    defaults,noatime    0    1

これを行うと、アクセス時間に依存するアプリケーションが破損します。考えられる解決策については、atimeoptions を参照してください。

コミット間隔の増加

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

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

/etc/fstab

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

バリアとパフォーマンス

カーネル 2.6.30 から、データの整合性を確保するのに役立つ変更によって ext4 のパフォーマンスは落ちています [5]。

多くのファイルシステム (XFS, ext3, ext4, reiserfs) では、fsync やトランザクションコミットの際に書き込みバリアと呼ばれるものをディスクに送信します。書き込みバリアは書き込みの順序を守らせるための仕組みで (いくらか性能面への影響があります)、ディスクの書き込みキャッシュを安全に利用できるようにするためのものです。お使いのディスクにバッテリーが搭載されているような場合は、バリアを無効化することで性能を改善できる場合があります。

書き込みバリアの送信は、マウントオプションに barrier=0 (ext3, ext4, reiserfs の場合) や nobarrier (XFS) を設定することで無効化できます [6]。

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

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

/etc/fstab

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

ジャーナリングの無効化

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

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

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

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

この記事あるいはセクションで使われている用語や表現には問題が存在します。

議論: Complicated to read, needs style fixing. (議論: トーク:Ext4#)

データの整合性とパフォーマンスの両方に懸念がある場合は、 journal_async_commit マウントオプションを使用してジャーナリングを大幅に高速化できます。これは動作しませんバランスの取れたデフォルトの data=ordered であるため、これはファイルシステムがすでに慎重になっている場合にのみ推奨されることに注意してください。 data=journal を使用します。

次に、 mke2fs -O journal_dev /dev/journal_device を使用して、ジャーナルの専用デバイスをフォーマットできます。 tune2fs -J device=/dev/journal_device/dev/ext4_fs を使用してジャーナルを既存のデバイスに割り当てるか、新しいファイルシステムを作成する場合 tune2fs を mkfs.ext4 に置き換えます。

ヒントとテクニック

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

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

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

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

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

パフォーマンスへの影響

こちらのベンチマークによれば intel モジュールは generic モジュールよりも平均で10倍、最大で20倍高速です。

参照