Ext4

関連記事

• ファイルシステム
• Ext3

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

ソース: Ext4 - Linux Kernel Newbies

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

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

# mkfs.ext4 /dev/partition

ヒント: オプションについては mkfs.ext4 の man ページを見て下さい。/etc/mke2fs.conf を編集すればデフォルトのオプションを見たり設定できます。

デフォルトでは、mkfs.ext4 はやや低めの比率の bytes-per-inode を使って、作成される inode の定量を計算します。容量が 750GB 以上のパーティションではこれだと inode 番号が大きくなりすぎて、ディスク容量の無駄になります。比率は -i オプションで直接設定することができます。1/6291456 なら 2TB のパーティションで 476928 の inode になります。

ext3 から ext4 に移行

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

理由

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

利点:

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

欠点:

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

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

方法

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

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

理由

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

利点:

• パフォーマンスの向上と新機能 – 詳しくは Ext4 - Linux Kernel Newbies を見て下さい

欠点:

• 一方通行 (ext4 パーティションを ext3 に'ダウングレード'することはできません)

方法

以下の手順は http://ext4.wiki.kernel.org/index.php/Ext4_Howto と https://bbs.archlinux.org/viewtopic.php?id=61602 から引用しています。

警告: エクステントなどのオプションを有効にしないかぎり ext4 は ext3 と後方互換性があります。ただし、パーティションを完全に変換しない場合、ext4 を使用する利点は少なくなります。

1. バックアップを行なって下さい。ext4 に変換する ext3 パーティションに存在するデータを全てバックアップします。特に / (root) パーティションをバックアップする場合は、Clonezilla が役に立ちます。
2. /etc/fstab を編集して ext4 に変換するパーティションの 'type' を ext3 から ext4 に変換してください。
3. (必要であれば) ライブメディアを起動します。e2fsprogs で変換を行う際はドライブがマウントされていない状態になっている必要があります。ドライブの root (/) パーティションを変換するときは、他のライブメディアから起動して変換するのが一番簡単です。
4. パーティションがマウントされていないことを確認してください
5. tune2fs -O extent,uninit_bg,dir_index /dev/sdxX を実行 (/dev/sdxX は変換するパーティションのパスに置き換えて下さい、例: /dev/sda1)
6. fsck -f /dev/sdxX を実行
7. 推奨: パーティションをマウントして e4defrag -c -v /dev/sdxX を実行
8. Arch Linux を再起動してください

ノート: The user MUST fsck the filesystem, or it will be unreadable! This fsck run is needed to return the filesystem to a consistent state. It WILL find checksum errors in the group descriptors -- this is expected. The '-f' parameter asks fsck to force checking even if the file system seems clean. The '-p' parameter asks fsck to 'automatically repair' (otherwise, the user will be asked for input for each error). You may need to run fsck -f rather than fsck -fp.

ノート: Even though the filesystem is now converted to ext4, all files that have been written before the conversion do not yet take advantage of the extent option of ext4, which will improve large file performance and reduce fragmentation and filesystem check time. In order to fully take advantage of ext4, all files would have to be rewritten on disk. Use e4defrag to take care of this problem.

警告: root (/) パーティションを変換した場合、起動しようとした時にカーネルパニックが発生することがあります。カーネルパニックが起きる場合、'fallback' の initial ramdisk を使用して再起動して、'default' の initial ramdisk を再作成してください: mkinitcpio -p linux。

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

Linux 4.1以降、ext4はファイルベースの暗号化をサポートしています。暗号化用にマークされたディレクトリツリーでは、ファイルの内容、ファイル名、およびシンボリックリンクのターゲットはすべて暗号化されます。暗号化キーはカーネルキーリングに格納されます。機能の詳細、実装状態の概要、実用的な点、カーネル4.1でのテスト結果については、Quarkslabのブログの項目も参照してください。

CONFIG_EXT4_ENCRYPTIONオプションが有効になっているカーネルを使用していて、e2fsprogsパッケージが少なくともバージョン1.43以上であることを確認してください。

次に、ファイルシステムが暗号化にサポートしているブロックサイズを使用していることを確認します:

# tune2fs -l /dev/device | grep 'Block size'

Block size:               4096

# getconf PAGE_SIZE

4096

これらの値が同じでない場合、ファイルシステムは暗号化をサポートしないので絶対にこれ以上先には進まないでください。

次に、ファイルシステムの暗号化機能フラグを有効にします:

# tune2fs -O encrypt /dev/device

警告: 暗号化機能フラグを有効にすると、4.1より古いカーネルはファイルシステムをマウントできなくなります。

次に、暗号化するディレクトリを作成します:

# mkdir /encrypted

暗号化は空のディレクトリにしか適用できないことに注意してください。暗号化設定(または「暗号化ポリシー」)は、新しいファイルとサブディレクトリによって継承されます。既存のファイルの暗号化はまだサポートされていません。

今度は、新しい鍵を生成して鍵リングに追加します。キーリングをフラッシュする(再起動する)たびに、この手順を繰り返す必要があります:

# e4crypt add_key
Enter passphrase (echo disabled): 
Added key with descriptor [f88747555a6115f5]

警告: パスフレーズを忘れた場合、ファイルを解読する方法はありません！パスフレーズを設定した後にパスフレーズを変更することはまだできません。

ノート: パスフレーズに対する辞書攻撃を防ぐために、ランダムな ソルトが自動生成され、ext4ファイルシステムのスーパーブロックに保存されます。 パスフレーズとソルトの両方は、実際の暗号化キーを導出するために使用されます。暗号化を有効にした複数のext4ファイルシステムがマウントされている場合、e4crypt add_keyは実際にはファイルシステムごとに1つずつ複数のキーを追加します。どんなキーもどんなファイルシステムでも使うことができますが、どのファイルシステムでもそのファイルシステム自身のソルトを使っているキーだけを使うのが賢明でしょう。そうでない場合、ファイルシステムBがアンマウントされていると、ファイルシステムAのファイルを解読することができなくなります。あるいは、-Sオプションをe4crypt add_keyに使用して自分でソルトを指定することもできます。

これであなたのキーの記述子が分かりました。 キーがセッションキーリングに含まれていることを確認します:

# keyctl show
Session Keyring
1021618178 --alswrv   1000  1000  keyring: _ses
 176349519 --alsw-v   1000  1000   \_ logon: ext4:f88747555a6115f5

ほとんど完了しました。次に、ディレクトリに暗号化ポリシーを設定します(キーを割り当てます)。:

# e4crypt set_policy f88747555a6115f5 /encrypted

以上です。キーリングにキーを追加せずにディレクトリにアクセスしようとすると、ファイル名とその内容は暗号化されたように見えます。

Tips and tricks

予約ブロックの削除

デフォルトでは、ファイルシステムの 5% はフラグメントが起こらないように root ユーザーに予約されます。最近の大容量ディスクでは、パーティションを長期保存アーカイブとして使う場合、5%は必要以上に大きい値となります (詳しくは このメール を見て下さい)。パーティションが以下の条件を満たしているならば、ディスク容量を増やすために予約ブロックの割合を減らしても大抵は問題ありません:

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

予約ブロックを削減するには tune2fs ユーティリティを使います。次のコマンドは /dev/sdXY パーティションの予約ブロックの割合を 1.0% に設定します:

# tune2fs -m 1.0 /dev/sdXY

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

$ findmnt /the/mount/point

E4rat

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

バリアとパフォーマンス

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

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

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

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

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

/etc/fstab

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

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

In both cases of enabling metadata checksums for new and existing filesystems, you will need to load some kernel modules.

If your CPU supports SSE 4.2, make sure the crc32c_intel kernel module is loaded in order to enable the hardware accelerated CRC32C algorithm. If not you will need to load the crc32c_generic module.

If this is the root file-system your crc32c_ module might need to be added to /etc/mkinitcpio.conf:

   MODULES="... crc32c_intel crc32c_generic"

And then regenerate the initramfs. See Mkinitcpio#Image creation and activation.

After this, you are ready to enable support for metadata checksums as described in the following two sections. In both cases the file system must not be mounted.

More about metadata checksums can be read on the ext4 wiki.

New filesystem

To enable support for ext4 metadata checksums on a new file system make sure that you have e2fsprogs 1.43 or newer and simply do a:

# mkfs.ext4 /dev/path/to/disk

The metadata_csum and 64bit options will be enabled by default.

The file-system can then be mounted as usual.

Existing filesystem

To enable support on an existing ext4 file system do the following.

This needs to be done with the partition unmounted, so if you want to convert the root, you'll need to run off an USB live distro.

First the partition needs to be checked and optimized using:

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

Then the file-system needs to be converted to 64bit:

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

Finally checksums can be added

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

The file-system can then be mounted as usual.

You can check whether the features were successfully enabled by running:

# dumpe2fs /dev/path/to/disk

Impact on performance

Keep in mind that the intel module consistently performs 10x faster than the generic one, peaking at 20x faster as can be seen in this benchmark.

参照

• Official Ext4 wiki
• Ext4 Disk Layout described in its wiki
• Ext4 Encryption LWN article
• Kernel commits for ext4 encryption [3] [4]
• e2fsprogs Changelog
• Ext4 Metadata Checksums