Linuxファイルシステムを理解する：ext4以降

最近のLinuxディストリビューションの大部分はデフォルトでext4ファイルシステムになっています。これは、以前のLinuxディストリビューションがデフォルトでext3、ext2、そして（十分に遡ると）extになっているのと同じです。

Linux（またはファイルシステム）を初めて使用する場合は、ext3が提供しなかったext4がテーブルに何をもたらすのか疑問に思われるかもしれません。また、btrfs、xfs、zfsなどの代替ファイルシステムのニュース報道が急増していることを考えると、ext4がまだ活発に開発されているかどうか疑問に思うかもしれません。

その他のLinuxリソース

Linuxコマンドのチートシート
高度なLinuxコマンドのチートシート
無料のオンラインコース：RHELの技術概要
Linuxネットワーキングのチートシート
SELinuxチートシート
Linuxの一般的なコマンドのチートシート
Linuxコンテナとは何ですか？
最新のLinux記事

ファイルシステムに関するすべてを1つの記事で網羅することはできませんが、Linuxのデフォルトのファイルシステムの歴史、現在の状況、および何を期待するかについて、理解を深めることができます。

この概要を準備する際に、ウィキペディアのさまざまなextファイルシステムの記事、kernel.orgのext4に関するwikiエントリ、および私自身の経験を大いに活用しました。

extの簡単な歴史

MINIXファイルシステム

extが存在する前は、MINIXファイルシステムが存在していました。 Linuxの歴史に精通していない場合、MINIXはIBM PC/ATマイクロコンピューター用の非常に小さなUnixライクなオペレーティングシステムでした。 Andrew Tannenbaumは教育目的で開発し、1987年にソースコードを（印刷形式で！）リリースしました。

MINIXのソースを熟読することはできますが、実際には無料のオープンソースソフトウェア（FOSS）ではありませんでした。 Tannebaumの本の出版社は、MINIXを運営するために69ドルのライセンス料を要求しましたが、これは本の費用に含まれていました。それでも、これは当時は信じられないほど安価であり、MINIXの採用は急速に始まり、オペレーティングシステムのコーディングを教えるためだけに使用するというTannenbaumの当初の意図をすぐに超えました。 1990年代までに、世界中の大学でMINIXのインストールが盛んになり、若いLinus TorvaldsはMINIXを使用してオリジナルのLinuxカーネルを開発しました。これは、1991年に最初に発表され、1992年12月にGPLの下でリリースされました。

しかし、待ってください。これはファイルシステムです。記事でしょ？はい。MINIXには独自のファイルシステムがあり、Linuxの初期バージョンもこれに依存していました。 MINIXと同様に、この種の「おもちゃ」の例として説明することもできます。MINIXファイルシステムは、最大14文字のファイル名しか処理できず、64MBのストレージしかアドレス指定できませんでした。 1991年には、一般的なハードドライブのサイズはすでに40〜140MBでした。 Linuxには明らかにより良いファイルシステムが必要でした！

ext

Linusが新しいLinuxカーネルをハッキングしている間、RémyCardは最初のextファイルシステムで動作しました。 Linux自体が最初に発表されてからわずか1年後の1992年に最初に実装されました！extは、MINIXファイルシステムの最悪の問題を解決しました。

1992年のextは、Linuxカーネルの新しい仮想ファイルシステム（VFS）抽象化レイヤーを使用していました。以前のMINIXファイルシステムとは異なり、extは最大2GBのストレージをアドレス指定し、255文字のファイル名を処理できました。

しかし、extは、主にその原始的なタイムスタンプ（iノードの作成、ファイルアクセス、およびファイル変更のための3つの別々のスタンプではなく、ファイルごとに1つのタイムスタンプのみ）のために、長い統治を持っていませんでした。わずか1年後、ext2は昼食を食べました。

ext2

レミーは、1年後にext2を代わりに設計したため、extの制限をすぐに認識しました。 extはまだ「おもちゃ」のオペレーティングシステムにルーツを持っていましたが、ext2は、BSDのBerkeley Fast File Systemと同じ原則に沿って、最初から商用グレードのファイルシステムとして設計されました。

Ext2は、ギガバイト単位の最大ファイルサイズとテラバイト単位のファイルシステムサイズを提供し、1990年代の大リーグにしっかりと位置付けました。これは、Linuxカーネルと最終的にはMINIXの両方で、またMacOSとWindowsで利用できるようにするサードパーティのモジュールによって、迅速かつ広く採用されました。

ただし、解決すべき問題はまだありました。1990年代のほとんどのファイルシステムと同様に、ext2ファイルシステムは、データのディスクへの書き込み中にシステムがクラッシュしたり電源が切れたりすると、壊滅的な破損が発生する傾向がありました。また、時間の経過とともに断片化（1つのファイルを複数の場所に保存し、回転するディスクの周囲に物理的に分散させる）により、パフォーマンスが大幅に低下しました。

これらの問題にもかかわらず、ext2は今日でもいくつかの孤立したケースで使用されています。最も一般的には、ポータブルUSBサムドライブのフォーマットとして使用されています。

ext3

ext2の採用から6年後の1998年、StephenTweedieは大幅な改善に取り組んでいると発表しました。これはext3になり、2001年11月にカーネルバージョン2.4.15でメインラインLinuxに採用されました。

Ext2は、ほとんどの場合Linuxディストリビューションで非常にうまく機能していましたが、FAT、FAT32、HFS、および当時の他のファイルシステムのように、電力損失時に壊滅的な破損が発生する傾向がありました。ファイルシステムへのデータの書き込み中に電源が切れると、一貫性のないと呼ばれる状態のままになる可能性があります。状態—物事が半分行われ、半分行われなかった状態。これにより、保存されているファイルとは関係のない膨大な量のファイルが失われたり破損したり、ファイルシステム全体がマウントできなくなったりする可能性があります。

Ext3、およびMicrosoftのNTFSなどの1990年代後半の他のファイルシステムは、ジャーナリングを使用します。この問題を解決するために。ジャーナルは、書き込みがトランザクションに格納されるディスク上の特別な割り当てです。トランザクションがディスクへの書き込みを終了すると、ジャーナル内のデータはコミットされます ファイルシステム自体に。システムがクラッシュする場合その操作がコミットされる前に、新しく再起動されたシステムはそれを不完全なトランザクションとして認識し、発生したことがないかのようにロールバックします。これは、作業中のファイルがまだ失われる可能性があることを意味しますが、ファイルシステム自体は一貫性を保ち、他のすべてのデータは安全です。 ext3のLinuxカーネル実装では、次の3つのレベルのジャーナリングを使用できます。ジャーナル 、注文済み 、および書き戻し 。

ジャーナル は最もリスクの低いモードであり、ファイルシステムにコミットする前にデータとメタデータの両方をジャーナルに書き込みます。これにより、書き込まれるファイルとファイルシステム全体の一貫性が確保されますが、パフォーマンスが大幅に低下する可能性があります。
注文済み ほとんどのLinuxディストリビューションのデフォルトモードです。順序付きモードはメタデータをジャーナルに書き込みますが、データをファイルシステムに直接コミットします。名前が示すように、注文ここでの操作は厳密です。まず、メタデータがジャーナルにコミットされます。次に、データがファイルシステムに書き込まれ、その後、ジャーナル内の関連するメタデータがファイルシステム自体にフラッシュされます。これにより、クラッシュが発生した場合でも、不完全な書き込みに関連付けられたメタデータがジャーナルに残り、ファイルシステムはジャーナルをロールバックしながらそれらの不完全な書き込みをサニタイズできます。順序付きモードでは、クラッシュにより、クラッシュ中にアクティブに書き込まれている1つまたは複数のファイルが破損する可能性がありますが、ファイルシステム自体（およびアクティブに書き込まれていないファイル）は安全であることが保証されます。
書き戻し 3番目の（そして最も安全性の低い）ジャーナルモードです。順序付きモードと同様に、ライトバックモードでは、メタデータはジャーナル処理されますが、データはジャーナル処理されません。順序付きモードとは異なり、メタデータとデータは、最高のパフォーマンスを得るために意味のある順序で書き込むことができます。これによりパフォーマンスが大幅に向上しますが、安全性は大幅に低下します。ライトバックモードでもファイルシステム自体の安全性が保証されますが、またはの間に書き込まれたファイルクラッシュする前に、損失や破損に対して脆弱です。

その前のext2と同様に、ext3は16ビットの内部アドレス指定を使用します。つまり、ブロックサイズが4Kの場合、処理できる最大のファイルサイズは2 TiBで、最大ファイルシステムサイズは16TiBです。

ext4

セオドア・ツォ（当時はext3の主な開発者でした）は2006年にext4を発表し、2年後にカーネルバージョン2.6.28でメインラインLinuxに追加されました。 Ts'oは、ext4を、ext3を大幅に拡張するが、依然として古いテクノロジーに依存している一時的なテクノロジーとして説明しています。彼は、最終的には真の次世代ファイルシステムに取って代わられることを期待しています。

Ext4は機能的にext3と非常に似ていますが、大規模なファイルシステムのサポート、断片化に対する耐性の向上、パフォーマンスの向上、タイムスタンプの向上をもたらします。

Ext4とext3

Ext3とext4にはいくつかの非常に具体的な違いがあり、ここで焦点を当てます。

下位互換性

Ext4は、ext3と可能な限り下位互換性があるように特別に設計されています。これにより、ext3ファイルシステムをext4にアップグレードできるだけでなく、また、ext4ドライバーがext3ファイルシステムをext3モードで自動的にマウントできるようにするため、2つのコードベースを別々に維持する必要がなくなります。

大規模なファイルシステム

Ext3ファイルシステムは32ビットアドレス指定を使用し、2TiBファイルと16TiBファイルシステムに制限しました（4 KiBブロックサイズを想定。一部のext3ファイルシステムはより小さなブロックサイズを使用するため、さらに制限されます）。

Ext4は48ビットの内部アドレス指定を使用するため、理論的には最大1,000,000 TiB（1 EiB）のファイルシステムに最大16TiBのファイルを割り当てることができます。 ext4の初期の実装は、一部のユーザーランドユーティリティによってまだ16 TiBファイルシステムに制限されていましたが、2011年の時点で、e2fsprogsは>16TiBext4ファイルシステムの作成を直接サポートしています。一例として、Red Hat EnterpriseLinuxは契約上最大50TiBのext4ファイルシステムのみをサポートし、100TiB以下のext4ボリュームを推奨しています。

割り当ての改善

Ext4では、ストレージブロックをディスクに書き込む前に割り当てる方法に多くの改善が加えられ、読み取りと書き込みの両方のパフォーマンスが大幅に向上する可能性があります。

エクステント

エクステントは、一度に予約およびアドレス指定できる連続した物理ブロックの範囲です（4 KiBのブロックサイズを想定すると、最大128 MiB）。エクステントを利用すると、特定のファイルに必要なiノードの数が減り、断片化が大幅に減り、大きなファイルを書き込むときのパフォーマンスが向上します。

マルチブロック割り当て

Ext3は、割り当てられた新しいブロックごとに1回ブロックアロケータを呼び出しました。これにより、複数のライターが同時に開いている場合に、簡単に大きな断片化が発生する可能性があります。ただし、ext4は遅延割り当てを使用するため、書き込みを統合し、まだコミットしていない書き込みにブロックを割り当てる方法についてより適切な決定を下すことができます。

永続的な事前割り当て

ファイルにディスクスペースを事前に割り当てる場合、ほとんどのファイルシステムは、作成時にそのファイルのブロックにゼロを書き込む必要があります。 Ext4ではfallocate()を使用できます代わりに、最初にスペースに書き込む必要なしに、スペースの可用性を保証します（そして、そのスペースの連続したスペースを見つけようとします）。これにより、ストリーミングおよびデータベースアプリケーションの書き込みデータと書き込みデータの将来の読み取りの両方でパフォーマンスが大幅に向上します。

割り当ての遅延

これは、歯ごたえのある、そして論争の的となる機能です。遅延割り当てにより、ext4は、データをディスクにコミットする準備ができるまで、データを書き込む実際のブロックの割り当てを待機できます。（対照的に、ext3は、データがまだ書き込みキャッシュに流れている間でも、ブロックをすぐに割り当てます。）

データがキャッシュに蓄積されるときにブロックの割り当てを遅らせることで、ファイルシステムはそれらのブロックの割り当て方法について賢明な選択を行うことができ、断片化（書き込みおよび後で読み取り）を減らし、パフォーマンスを大幅に向上させます。残念ながら、それは増加します fsync()を呼び出すように特別に作成されていないプログラムでデータが失われる可能性プログラマーがデータが完全にディスクにフラッシュされたことを確認したい場合。

プログラムがファイルを完全に書き換えるとします：

fd=open("file" ,O_TRUNC); write(fd, data); close(fd);

従来のファイルシステムでは、close(fd); fileの内容を保証するには十分ですディスクにフラッシュされます。書き込みは厳密に言えばトランザクションではありませんが、後にクラッシュが発生した場合にデータが失われるリスクはほとんどありません。ファイルが閉じられます。

書き込みが成功しない場合（プログラムのエラー、ディスクのエラー、電力損失などが原因）、元のバージョンとの両方新しいバージョンのファイルが失われたり、破損したりする可能性があります。他のプロセスが書き込み中にファイルにアクセスすると、破損したバージョンが表示されます。また、他のプロセスがファイルを開いていて、その内容が変更されることを期待していない場合（たとえば、複数の実行中のプログラムにマップされた共有ライブラリ）、それらはクラッシュする可能性があります。

これらの問題を回避するために、一部のプログラマーはO_TRUNCの使用を避けていますまったく。代わりに、新しいファイルに書き込んで閉じてから、古いファイルの名前を変更する場合があります。

fd=open("newfile"); write(fd, data); close(fd); rename("newfile", "file");

ファイルシステムの下でなし割り当てが遅れる場合、これは上記で概説した潜在的な破損とクラッシュの問題を回避するのに十分です。rename() 不可分操作であり、クラッシュによって中断されることはありません。実行中のプログラムは、リンクされていない古いバージョンのfileを引き続き参照します。開いているファイルハンドルがある限り。ただし、ext4の割り当てが遅れると、書き込みが遅れて並べ替えられる可能性があるため、rename("newfile","file") 前に実行できます newfileの内容実際にはディスクに書き込まれるため、並列プロセスが不正なバージョンのfileを取得するという問題が発生します。もう一度。

これを軽減するために、Linuxカーネル（バージョン2.6.30以降）は、これらの一般的なコードケースを検出し、問題のファイルをすぐに割り当てようとします。これにより、データ損失の可能性が減少しますが、防止することはできません。また、新しいファイルではまったく役に立ちません。開発者の方は、次の点に注意してください：のみデータがすぐにディスクに書き込まれることを保証する方法は、fsync()を呼び出すことです。適切に。

無制限のサブディレクトリ

Ext3は合計32,000のサブディレクトリに制限されていました。 ext4は無制限の数を許可します。カーネル2.6.23以降、ext4はHTreeインデックスを使用して、膨大な数のサブディレクトリでのパフォーマンスの低下を軽減します。

ジャーナルチェックサム

Ext3はジャーナルをチェックサムしませんでした。これは、カーネルの直接制御の範囲外で、独自のキャッシュを持つディスクまたはコントローラーデバイスに問題をもたらしました。コントローラまたは独自のキャッシュを備えたディスクが順不同で書き込みを行った場合、ext3のジャーナリングトランザクションの順序が崩れ、クラッシュ中（またはクラッシュ前のしばらくの間）に書き込まれたファイルが破損する可能性があります。

理論的には、この問題は書き込みバリアを使用することで解決されます。ファイルシステムをマウントするときに、barrier=1を設定します。マウントオプションで、デバイスはfsync()を尊重します金属までずっと呼び出します。実際には、ストレージデバイスとコントローラーは頻繁に実行しないことが発見されています。書き込みの障壁を尊重します。パフォーマンス（および競合他社と比較した場合のベンチマーク）は向上しますが、防止すべきデータ破損の可能性が広がります。

ジャーナルをチェックサムすると、ファイルシステムは、クラッシュ後の最初のマウントで、そのエントリの一部が無効であるか、順序が正しくないことを認識できます。これにより、ストレージデバイスが嘘をつき、障壁を尊重していなくても、部分的または順不同のジャーナルエントリをロールバックし、ファイルシステムにさらに損害を与えるという間違いを回避できます。

高速ファイルシステムチェック

ext3では、ファイルシステム全体（削除されたファイルと空のファイルを含む）で、fsckのタイミングを確認する必要がありました。が呼び出されます。対照的に、ext4は、iノードテーブルの未割り当てのブロックとセクションをそのようにマークし、fsckを許可します。それらを完全にスキップします。これにより、fsckの実行時間が大幅に短縮されます。ほとんどのファイルシステムで、カーネル2.6.24以降に実装されています。

タイムスタンプの改善

Ext3は、1秒にきめ細かいタイムスタンプを提供しました。ほとんどの用途には十分ですが、ミッションクリティカルなアプリケーションは、はるかに厳密な時間制御を頻繁に求めています。 Ext4は、ナノ秒単位のタイムスタンプを提供することにより、エンタープライズ、科学、およびミッションクリティカルなアプリケーションで利用できるようにします。

Ext3ファイルシステムも2038年1月18日以降の日付を格納するのに十分なビットを提供しませんでした。Ext4はここにさらに2ビットを追加し、Unixエポックをさらに408年延長します。西暦2446年にこれを読んでいる場合は、すでにより良いファイルシステムに移行していることを願っていますが、1970年1月1日のUTC 00:00以降の時間を測定している場合は、死後非常に満足しています。

オンラインでの最適化

ext2もext3も、オンラインでの最適化を直接サポートしていませんでした。つまり、マウント中にファイルシステムを最適化することはできませんでした。 Ext2には、 e2defragというユーティリティが含まれていました。、それは名前が意味することをしました—しかし、ファイルシステムがマウントされていない間、それはオフラインで実行される必要がありました。（これは明らかに、ルートファイルシステムにとって特に問題です。）ext3の状況はさらに悪化しました。ただし、ext3は、 e2defrag を実行している場合、ext2よりも深刻な断片化に悩まされる可能性ははるかに低くなりました。 ext3ファイルシステムに対しては、壊滅的な破損とデータ損失が発生する可能性があります。

ext3は元々「断片化の影響を受けない」と見なされていましたが、同じファイルへの超並列書き込みプロセスを使用するプロセス（BitTorrentなど）は、これが完全に当てはまるわけではないことを明らかにしました。 Shakeなどのいくつかのユーザースペースのハッキングと回避策は、何らかの方法でこれに対処しましたが、実際のファイルシステム対応のカーネルレベルのデフラグプロセスよりも遅く、さまざまな点で満足のいくものではありませんでした。

Ext4は、 e4defragを使用してこの問題に正面から取り組んでいます。、オンライン、カーネルモード、ファイルシステム対応、ブロックおよびエクステントレベルの最適化ユーティリティ。

進行中のext4開発

Ext4は、 Monty Python 疫病の犠牲者はかつて「まだ完全に死んでいない！」と言った。その主要な開発者は、それを真の次世代ファイルシステムへの道のりの単なる一時的なものと見なしていますが、ルートファイルシステムとしての展開の準備ができている可能性のある候補はまだありません（技術的またはライセンス上の問題のため）。

メタデータのチェックサム、ファーストクラスのクォータのサポート、大規模な割り当てブロックなど、ext4の将来のバージョンに開発されている主要な機能がまだいくつかあります。

メタデータチェックサム

ext4には冗長なスーパーブロックがあるため、その中のメタデータをチェックサムすることで、ファイルシステムは、プライマリスーパーブロックが破損していて、代替スーパーブロックを使用する必要があるかどうかを判断できます。チェックサムなしで破損したスーパーブロックから回復することは可能ですが、ユーザーはまず、それがであったことを認識する必要があります。破損している場合は、別の方法を使用してファイルシステムを手動でマウントしてみてください。破損したプライマリスーパーブロックを使用してファイルシステムの読み取り/書き込みをマウントすると、場合によってはさらに損傷を引き起こす可能性があるため、十分な経験を積んだユーザーであっても、これは十分な解決策ではありません。

btrfsやzfsなどの次世代ファイルシステムによって提供される非常に堅牢なブロックごとのチェックサムと比較すると、ext4のメタデータチェックサムはかなり弱い機能です。しかし、何もないよりははるかに優れています。

当たり前のように聞こえますが（はい、すべてをチェックサムします！）、事後にチェックサムをファイルシステムにボルトで固定することにはいくつかの重要な課題があります。ざらざらした詳細については、設計ドキュメントを参照してください。

ファーストクラスのクォータサポート

待って、クォータ？ ext2の日からそれらを持っています！はい、しかし、彼らは常に後付けであり、彼らはいつもちょっと吸い込まれてきました。ここで詳細を説明する価値はないかもしれませんが、設計ドキュメントでは、クォータをユーザースペースからカーネルに移動し、より正確かつパフォーマンスを向上させる方法について説明しています。

大きな割り当てブロック

時間が経つにつれて、それらの厄介なストレージシステムはどんどん大きくなっていきます。一部のソリッドステートドライブはすでに8Kハードウェアブロックサイズを使用しているため、ext4の現在の4Kブロックへの制限はますます制限されています。ストレージブロックを大きくすると、「スラック」スペース（ファイルまたはファイルの最後の部分を保存するためにブロックの一部のみが必要な場合に残されるスペース）が増える代わりに、断片化が減少し、パフォーマンスが大幅に向上します。

ヘアの詳細は、設計ドキュメントで確認できます。

ext4の実際的な制限

Ext4は堅牢で安定したファイルシステムであり、ほとんどの人が2018年にルートファイルシステムとして使用するはずです。しかし、すべてを処理できるわけではありません。 すべきでないいくつかのことについて簡単に話しましょう ext4に期待する—現在またはおそらく将来。

ext4は最大1EiB（1,000,000 TiBに相当）のデータをアドレス指定できますが、実際には本当に そうしようとすべきではありません。より多くのブロックのアドレスを単に記憶できる以上の規模の問題があり、ext4は現在（そしておそらくこれからも）50-100TiBのデータをはるかに超えて拡張することはありません。

Ext4は、データの整合性を保証するのにも十分ではありません。ジャーナリングがext3の時代に戻ったのと同じくらい大きな進歩ですが、データ破損の一般的な原因の多くをカバーしていません。障害のあるハードウェア、宇宙線の影響（はい、実際）、または時間の経過に伴うデータの単純な劣化によって、データがすでにディスク上にある間に破損した場合、ext4にはそのような破損を検出または修復する方法がありません。

最後の2つの項目に基づいて、ext4は純粋なファイルシステムにすぎません。、およびストレージボリュームマネージャーではありません。これは、複数のディスクがある場合でも、つまり理論的には破損したデータを回復できるパリティまたは冗長性がある場合でも、ext4にはそれを認識したり、利益のために使用したりする方法がないことを意味します。理論的には可能ですが自動破損検出および修復機能を失うことなく、ファイルシステムとストレージボリューム管理システムを個別のレイヤーに分離することは、現在のストレージシステムの設計方法ではなく、新しい設計に重大な課題をもたらします。

代替ファイルシステム

始める前に、警告の言葉：非常に 組み込まれておらず、直接サポートされていない代替ファイルシステムには注意してください ディストリビューションのメインラインカーネルの一部として！

ファイルシステムが安全であっても、それをルートファイルシステムとして使用すると、カーネルのアップグレード中に問題が発生した場合、絶対に恐ろしいことがあります。 極端にでない場合代替メディアから起動し、chrootからカーネルモジュール、grub構成、およびDKMSを手動で辛抱強く突くというアイデアに慣れています...重要なシステムのルートファイルシステムで予約を取り消さないでください。

ディストリビューションが直接サポートしていないファイルシステムを使用するのには十分な理由があるかもしれませんが、使用する場合は、後にマウントすることを強くお勧めします。システムは稼働していて使用可能です。（たとえば、ext4ルートファイルシステムがあるが、ほとんどのデータをzfsまたはbtrfsプールに保存している場合があります。）

XFS

XFSは、非extファイルシステムがLinuxで取得するのとほぼ同じくらいメインラインです。これは64ビットのジャーナリングファイルシステムであり、2001年からLinuxカーネルに組み込まれており、大規模なファイルシステムで高いパフォーマンスと高度な同時実行性を提供します（つまり、非常に多くのプロセスがすべて一度にファイルシステムに書き込みます）。

XFSは、RHEL 7以降、Red Hat Enterprise Linuxのデフォルトのファイルシステムになりました。ホームユーザーや小規模ビジネスユーザーにとっては、まだいくつかの欠点があります。特に、既存のXFSファイルシステムのサイズを変更するのは非常に面倒です。別のものを作成してデータをコピーする感覚。

XFSは安定していてパフォーマンスが優れていますが、デフォルトではない場所（RHEL7など）での使用を推奨するために、XFSとext4の間に具体的な最終用途の違いは十分ではありません。 50を超えるTiB容量のファイルシステムなど、ext4で発生している特定の問題に対処します。

XFSは、ZFS、btrfs、さらにはWAFL（独自のSANファイルシステム）のように、決して「次世代」のファイルシステムではありません。 ext4と同様に、より良いものへの道のりの一時的なギャップと見なされる可能性があります。

ZFS

ZFSはSunMicrosystemsによって開発され、理論的には大規模なストレージシステムに対応できるため、ゼタバイト（1兆ギガバイトに相当）にちなんで名付けられました。

真の次世代ファイルシステムであるZFSは、ボリューム管理（単一のファイルシステム内の複数の個別のストレージデバイスに対応する機能）、ブロックレベルの暗号化チェックサム（非常に高い精度でデータ破損を検出できる）、自動破損修復（冗長ストレージまたはパリティストレージが利用可能です）、高速非同期インクリメンタルレプリケーション、インライン圧縮など。もっとたくさん。

Linuxユーザーの観点から見たZFSの最大の問題は、ライセンスです。 ZFSはCDDLのライセンスを取得しました。これは、GPLと競合するセミパーミッシブライセンスです。 LinuxカーネルでZFSを使用することの意味については多くの論争があり、「GPL違反だ」、「CDDL違反だ」、「まったく問題ない、法廷でテストされていない」などの意見があります。「」最も注目すべきは、Canonicalは、2016年以降、これまでのところ法的な異議申し立てなしに、デフォルトのカーネルにZFSコードをインラインで組み込んでいます。

現時点では、非常に 熱心なZFSユーザー自身、ルートLinuxファイルシステムとしてZFSをお勧めしません。 LinuxでZFSの利点を活用したい場合は、ext4で小さなルートファイルシステムをセットアップしてから、残りのストレージにZFSを配置し、データやアプリケーションなどを好きなように配置します。ただし、ディストリビューションが明示的になるまで、ext4をルートのままにします。 zfsルートをサポートします。

btrfs

Btrfs（B-Tree Filesystemの略で、通常は「バター」と発音されます）は、2007年にOracleでの在職中にChrisMasonによって発表されました。 Btrfsは、ZFSとほとんど同じ目標を目指しており、複数のデバイス管理、ブロックごとのチェックサム、非同期レプリケーション、インライン圧縮などを提供します。

2018年の時点で、btrfsはかなり安定しており、標準のシングルディスクファイルシステムとして使用できますが、ボリュームマネージャーとして信頼するべきではありません。多くの一般的なユースケースでext4、XFS、またはZFSと比較して重大なパフォーマンスの問題が発生し、その次世代機能（レプリケーション、複数ディスクトポロジ、スナップショット管理）はかなりバグが多く、結果は壊滅的なパフォーマンス低下にまで及ぶ可能性があります。実際のデータ損失に。

btrfsの現在の状況については議論の余地があります。 SUSE Enterprise Linuxは2015年にデフォルトのファイルシステムとして採用しましたが、RedHatは2017年にRHEL7.4以降のbtrfsをサポートしないことを発表しました。btrfsの本番環境でサポートされているデプロイメントでは単一ディスクファイルシステムとして使用されることに注意してください。ないマルチディスクボリュームマネージャーとしてala ZFS-ストレージアプライアンスでbtrfsを使用するSynologyでさえ、ディスクを管理するために従来のLinuxカーネルRAID（mdraid）の上にレイヤー化します。