コンテンツにスキップ

ext4

出典: フリー百科事典『ウィキペディア（Wikipedia）』
ext4
開発者 Mingming Cao, Andreas Dilger, Alex Zhuravlev (Tomas), Dave Kleikamp, セオドア・ツォー, Eric Sandeen, Sam Naghshineh 他
正式名 Fourth extended file system
導入 2006年10月10日 (Linux 2.6.19)
パーティション識別子 0x83 (MBR)
EBD0A0A2-B9E5-4433-
87C0-68B6B72699C7 (GPT)
構造
ディレクトリ テーブル, ツリー
領域管理 ビットマップ, テーブル
不良ブロック テーブル
限度
最大ファイル サイズ 16TiB
最大ボリューム サイズ 1EiB
ファイル名の文字 NULL('\0')と/以外使用可能
特徴
タイムスタンプ 変更, 属性変更, アクセス, 作成, 削除
日付範囲 1901年12月14日から2514年4月25日
日付分解能 ナノ秒
フォーク 可能
属性 No-atime, append-only, synchronous-write, no-dump, h-tree (directory), immutable, journal, secure-delete, top (directory), allow-undelete
パーミッション POSIX
透過的圧縮 できない
透過的暗号化 可能（Linux4.1から）
重複排除 無し
対応OS Linux
テンプレートを表示

ext4（fourth extended file system）は、Linuxのファイルシステムで、ジャーナリングファイルシステムの一つである。ext3の後継のファイルシステムで、拡張機能を使っていない場合に限りext3としてマウントできる。1EiBまでのストレージをサポートし、ファイルの断片化を防ぐextent file writingと呼ばれるシステムが導入される。ファイルのタイムスタンプは、ナノ秒単位で西暦1901年から2514年までの範囲をサポートする（ext3では秒単位で2038年まで）。Linuxカーネル 2.6.19より開発版が利用が可能になり、2.6.28[1]より安定版のファイルシステムとなった。

経緯

[編集]

ext3に対して後方互換性を保ちつつ、64ビットストレージの制限を除き、パフォーマンスを向上させるために開発が始められた[2]。しかしLinuxカーネルの開発者たちは、安定性に対する懸念から、ext3に拡張を加えることに反対した[3]。その代わり、ext3のソースコードから分岐してext4と改名し、現行のext3ユーザーに影響を及ぼすことなく開発を進めることを提案した。この提案は受け入れられ、2006年6月28日、ext3のメンテナであるセオドア・ツォー (Theodore Ts'o) は新しいプロジェクトとしてext4の開発を発表した[4]。

最初の開発スナップショットはLinux 2.6.19に導入された。2008年10月11日には、ext4を安定コードとしたパッチがLinux 2.6.28のソースコードリポジトリに結合された[5]。これは開発段階の終了を意味し、ext4の採用を推奨するものであった。ext4ファイルシステムを含むLinux 2.6.28は、2008年12月25日にリリースされた[6]。

特徴

[編集]
大きなボリュームサイズとファイルサイズ
ext4ファイルシステムは、最大1EiBまでのボリュームサイズ[7]と、最大16TiBまでのファイルサイズをサポートする。
エクステント
エクステント（英語版）は、ext2およびext3で使われてきた伝統的なブロックマッピング方式を置き換える概念である。エクステントは連続した物理ブロックの集合であり、大きなファイルに対するパフォーマンスを改善し、フラグメンテーションの発生を減らすことができる。ext4におけるエクステントは、4KiBのブロックサイズで最大128MiBまでの連続した領域をマッピングすることができる[2]。inodeごとに4つのエクステントを格納することができる。ひとつのファイルに5つ以上のエクステントがあるとき、残りのエクステントはHtreeで構造化される。エクステントを使用したいファイル毎にchattr（英語版）コマンドなどでの設定が必要。
後方互換性
ext4ファイルシステムはext3およびext2に対する後方互換性を持つ。すなわち、ext3およびext2ファイルシステムをext4ファイルシステムとしてマウントすることができる。その場合でも、わずかにパフォーマンスの向上が見られる。なぜなら、ブロック確保アルゴリズムなどの新しい機能はext3やext2でも使用できるからである。
ext3ファイルシステムは部分的にext4に対する前方互換性を持つ。すなわち、ext4ファイルシステムをext3パーティションとしてマウントできる（マウントするときは「ext3」をファイルシステムタイプとして指定する）。しかし、もしext4パーティションがエクステント（ext4の重要な新機能である）を使用しているなら、ext3としてマウントすることはできなくなる。
永続的な事前確保
ext4ファイルシステムはファイルのためのディスク空き領域の事前確保を可能にする。ほとんどのファイルシステムにおけるこれまでの方法論では、ファイルが作成されたときに予約されたスペースを0で埋める形で書き込まれる。ext4においてはこの方法で要求されることはもはやない。そのかわり、新しくfallocate()システムコールがLinuxカーネルにファイルシステム用に追加され、ext4やXFSにおいて使われている。これにより互換性が維持されている。ファイルのために確保されたスペースはディスクフルによる書き込み失敗はしないことが保証され、連続していることが期待される。この機能はメディアストリーミングやデータベースで使われる。
遅延確保
ext4ファイルシステムのパフォーマンス向上のテクニックとして、allocate-on-flushと呼ばれるものがある。これは遅延確保としても知られている。つまりext4では、データがディスクにフラッシュされるまでブロックの確保が遅延される(対して一部のファイルシステムでは、データが書き込みキャッシュに入れられる場合でも、ブロックは直ちに確保される)。より大きなデータを一度に効率的に確保することにより、遅延確保はパフォーマンスを向上させ、フラグメント化を減少させる。
サブディレクトリの32000個制限の撤廃
ext3ファイルシステムにおいては、1つのディレクトリに入れられるサブディレクトリ数が32,000個に制限されている。この制限がext4ファイルシステムでは65,000個まで引き上げられ、"dir_nlink"機能を使うとそれを超える事が可能となる（親ディレクトリのリンクカウント増加は止まるだろうが）。一つのディレクトリ内のファイル数が増えた場合における性能を上げる為、Htreeインデックス（B-treeの発展版）は、ext4でデフォルトでオンになった。この機能はLinux kernel 2.6.23 から導入されている。Htreeはext3でもdir_index機能が有効であれば利用可能であった。
ジャーナルのチェックサム
ext4は信頼性を向上するため、ジャーナルにチェックサムを使用する。なぜならばジャーナルはディスクで最も使用されるファイルの一つだからである。この機能によってジャーナル過程の間ディスクI/Oの待機を安全に避ける事ができるという利点を持つ。これによりパフォーマンスが若干向上する。ジャーナルのチェックサムのテクニックは『IRON File Systems』というウィスコンシン州立大学の研究論文にインスパイアされたものである。（とりわけ6章の『トランザクション・チェックサム』の部分）[8]
オンラインのデフラグメンテーション
e4defrag により、マウント中（オンライン）でのデフラグが可能になった。ファイルシステムのフラグメンテーションを避けるための様々なテクニックによってフラグメントしにくくなっているが、それでもなお、長期間運用されたファイルシステムは時間経過によってフラグメントが発生する場合がある[9]。
より高速なファイルシステムチェック
ext4において、確保されていないブロック群とi-nodeテーブル部は印をつけられる。これはe2fsckの実行時に全体のチェックを不要にし、ファイルシステムのチェックにかかる時間を大きく減少させる。この機能は2.6.24のLinuxカーネルで実装された。
マルチブロックの確保
ext3では、ファイルが追加される際にブロックアロケータをそれぞれのブロック個別に1回ずつ呼び出す。そのため、同時に複数書き込みを行う場合には、ディスク上でファイルのフラグメントは容易に発生する。しかし、ext4ではデータをバッファして複数のブロック群を一度に確保する遅延確保を利用する。これはアロケータは何を書き込むべきかについてより多くの情報を保持することを意味し、そしてディスク上のファイル領域確保のためより良い選択を行うことができるようになる。マルチブロックアロケータは遅延確保がファイルシステム上で有効になっているとき、もしくはファイルがO_DIRECTモードで開かれているときに使用される。この機能はディスクフォーマットには影響しない。
タイムスタンプの改良
コンピューターが全体的により高速になると共に、Linuxはよりミッションクリティカルな用途で使用されるようになり、秒ベースの粒度のタイムスタンプでは不十分となってきている。この解決として、ext4ではタイムスタンプをナノ秒単位で提供している。付け加えて、2038年問題を引き伸ばすためにタイムスタンプの秒フィールドの上位に2ビットの拡張タイムスタンプフィールドが付け加えられ、結果として204年後まで先延ばしにしている。
ext4は作成日時のタイムスタンプ(time-of-creation timestamps)を追加でサポートする。しかし、セオドア・ツォーが指摘するように、inodeに作成日時フィールドを追加する(つまり技術的にそのタイムスタンプのサポートをext4で可能にする)のは簡単であるものの、stat() (おそらく新しいバージョンが必要となる)などの必要なシステムコールや、それに依存する各ライブラリ(glibcなど)の変更や追加はより難しい。これらの変更は様々なプロジェクトでの調整が必要となる[10]。そのため、ext4に保存された作成日時は、現在のところLinux上のユーザプログラムに対してstatx() APIによってのみ提供される[11]。

欠点

[編集]

遅延割り当てとデータ損失

[編集]

遅延割り当て（delayed allocation）は、すべてのデータをディスクに書き出す前にファイルシステムがクラッシュした際、データを損失する危険性を孕む。

このようなことが起こる典型的なシナリオは、fsyncでディスクに書き出すことをせずにファイルの内容を書き換えるようなプログラムを使用する時である。実際に書き出しをする前にシステムがクラッシュすると、問題が起こる可能性がある。このような状況では、ext3のユーザーは、クラッシュ後に変更前か変更後のどちらかのデータがディスクに残されているということを期待することができた。一方、Linuxカーネル2.6.28のext4では、クラッシュ前にファイルの内容を消去するが新しいデータを書き出さず、結果としてデータが損失するということがしばしば見られた。

この問題に対処するためにfsyncを頻繁に使用すると、data=orderedフラグ（多くのLinuxディストリビューションではデフォルト）でマウントされたext3ファイルシステムでは深刻なパフォーマンス低下が起こる恐れがある。どちらのファイルシステムもしばらくの間使用されるだろうということを考えると、これはエンドユーザーアプリケーション開発者にとって非常に厄介な問題となる。このため、セオドア・ツォーは、上記のような場合の遅延割り当てを制限するext4のパッチを作成した。パフォーマンスは多少低下するが、これによってクラッシュ後にどちらかのバージョンのデータが残る可能性が著しく高まった。

このパッチはメインライン・カーネル2.6.30に導入されているが、様々なディストリビューションは2.6.28や2.6.29へとバックポートすることができる。例えば、Ubuntuはバージョン9.04 Jaunty Jackalopeでカーネル2.6.28にそのパッチを導入した。

Linuxカーネルの機能への影響

[編集]

ext4はLinuxに限れば標準的なファイルシステムであるため、実際にはext4以外では使用できない機能があたかもファイルシステムに依存しないLinuxカーネルの機能として追加されてしまうことがある。実例としてfallocate()がある。これはext4におけるファイルブロックの事前確保を実装したシステムコールであるが、これを期待通りのセマンティクスにて実装したファイルシステムはext4のみである。この影響で、POSIXでは類似機能のシステムコールをposix_fallocate()として別に仕様に入れたり[12]、ZFSにてfallocate()が本質的に実装できないことが機能不足として指摘されてしまう結果となった。

ディストリビューション

[編集]

以下の Linux ディストリビューションで標準ファイルシステムとして採用されている。

  • Ubuntu - 9.04 から利用可能、9.10 から標準
  • Debian - 6.0 から利用可能
  • Fedora - 9 から利用可能、11〜15 にて標準
  • Red Hat Enterprise Linux - 5.6 からフルサポート
  • Amazon Linux AMI - 2011.02 から標準

脚注

[編集]
  1. ^ Linux 2 6 28 - Linux Kernel Newbies
  2. ^ a b Mathur, Avantika (2007年). “The new ext4 filesystem: current status and future plans” (PDF). Proceedings of the Linux Symposium. Ottawa, ON, CA: Red Hat. 2008年1月15日閲覧。
  3. ^ Torvalds, Linus. “extents and 48bit ext3”. LKML. 2006年6月9日閲覧。
  4. ^ Ts'o, Theodore. “Proposal and plan for ext2/3 future development work”. LKML. 2006年6月28日閲覧。
  5. ^ “ext4: Rename ext4dev to ext4”. Linus' kernel tree. 2008年10月20日閲覧。
  6. ^ Leemhuis, Thorsten. “Higher and further: The innovations of Linux 2.6.28”. Heise Online. http://www.heise-online.co.uk/open/Kernel-Log-Higher-and-Further-The-innovations-of-Linux-2-6-28--/features/112299 2008年12月23日閲覧。 
  7. ^ “Migrating to Ext4”. DeveloperWorks. IBM. 2008年12月14日閲覧。
  8. ^ Vijayan Prabhakaran, et al. (PDF). IRON File Systems. CS Dept, University of Wisconsin. http://www.cs.wisc.edu/wind/Publications/iron-sosp05.pdf. 
  9. ^ http://kernelnewbies.org/Ext4#head-38e6ac2b5f58f10989d72386e6f9cc2ef7217fb0
  10. ^ Theodore Ts'o (2006年10月5日). “Re: creation time stamps for ext4 ?”. 2010年4月13日閲覧。
  11. ^ Edge, Jake (2017年3月31日). “Extending statx()”. 2019年4月20日閲覧。
  12. ^ posix_fallocate()は対象のファイルシステムがfallocate()をサポートしていない場合、実装依存でfallocate()のセマンティクスの一部をエミュレートすることができる。ただし、常にそうしなくとも構わない。fallocate()は対象のファイルシステムがこれをサポートしていない場合、常にエラーとする。

関連項目

[編集]

外部リンク

[編集]
ディスク
光ディスク / 磁気テープ
Flashメモリ / SSD
分散ファイルシステム
ネットワーク型
特殊用途
疑似・仮想
暗号化
その他
カテゴリ カテゴリ
スタブアイコン

この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。

「https://ja.wikipedia.org/w/index.php?title=Ext4&oldid=101043088」から取得