Linux ファイルシステムの説明: ext4 以降

今日は、ext3 や他の以前のファイル システムとの違いを含め、ext4 の歴史について説明します。

最近の Linux ディストリビューションのほとんどは、デフォルトで ext 4 ファイルシステムになっています。これは、古い Linux ディストリビューションがデフォルトで ext3、ext2、さらにもっと昔に遡れば ext だったのと同じです。
Linux やファイル システム全般を初めて使用する場合は、ext3 にはなくて ext4 にはどのような利点があるのか​​疑問に思うかもしれません。 btrfs、XFS、ZFS などの代替ファイルシステムに関するニュース報道を考えると、ext4 がまだ活発に開発中であるかどうかも疑問に思うかもしれません。
ファイルシステムについて知っておくべきことすべてを 1 つの記事で網羅することはできませんが、Linux のデフォルトのファイルシステムの歴史、現在の状況、そして期待されるものについて説明したいと思います。
この概要を書くにあたり、私はさまざまな ext ファイルシステムの記事や私自身の経験を参考にしました。

extの簡単な歴史

MINIX ファイル システム ext 以前は、MINIX ファイル システムが使用されていました。 Linux の歴史に詳しくない方のために説明すると、MINIX は IBM PC/AT マイクロコンピュータ用の非常に小さな Unix ライクなシステムでした。 Andrew Tannenbaum はこれを教育目的で開発し、1987 年にソース コード (印刷形式で!) をリリースしました。

IBM PC/AT 1980 年代中頃、MBlairMartin、CC BY-SA 4.0

MINIX のソースコードを閲覧することはできますが、実際にはフリー オープン ソース ソフトウェア (FOSS) ではありません。 Tannebaum の本の出版社は、MINIX を実行するために 69 ドルのライセンス料を支払うことを要求しており、この料金は本の価格に含まれています。それでも、当時としては非常に安価だったため、MINIX の使用は急速に増加し、オペレーティングシステムのコーディングを教えるために使用するという Tannebaum の当初の意図をすぐに超えていきました。 1990 年代を通じて、MINIX のインストールは世界中の大学で非常に人気がありました。当時、若き日の Linus Torvalds 氏は MINIX を使用してオリジナルの Linux カーネルを開発しました。このカーネルは 1991 年に初めて発表され、その後 1992 年 12 月に GPL オープンソース契約に基づいてリリースされました。
でも待ってください、これはファイルシステムの記事ですよね?はい、MINIX には独自のファイルシステムがあり、初期の Linux バージョンはそれに依存していました。 MINIX と同様に、Linux のファイル システムはおもちゃのように小さく、MINIX ファイル システムは最大 14 文字のファイル名を処理でき、64 MB のストレージ スペースしか処理できません。 1991 年までに、一般的なハード ドライブのサイズは 40 ～ 140 MB になりました。明らかに、Linux にはより優れたファイルシステムが必要です。

内線

Linus がまだ発展途上の Linux カーネルを開発していた頃、Rémy Card は ext ファイル システムの第 1 世代に取り組んでいました。 ext ファイル システムは、Linux が最初にリリースされてからわずか 1 年後の 1992 年に初めて実装され、リリースされました。 -- ext は、MINIX ファイル システムの最悪の問題を解決します。
1992 年の ext では、Linux カーネルの新しい仮想ファイル システム (VFS) 抽象化レイヤーが使用されました。以前の MINIX ファイル システムとは異なり、ext は最大 2 GB のストレージを処理でき、255 文字のファイル名を処理できます。
しかし、ext は、主にその原始的なタイムスタンプ (現在よく知られている inode、最終ファイル アクセス時刻、最終ファイル変更時刻のタイムスタンプではなく、ファイルごとに 1 つのタイムスタンプのみ) が原因で、長くは支配的ではありませんでした。わずか 1 年後、ext2 がこれに取って代わりました。

拡張子2

Rémy はすぐに ext の限界に気づき、1 年後には ext の代替として ext2 を設計しました。 ext は依然として「おもちゃ」のオペレーティング システムにルーツを持っていますが、ext2 は BSD の Berkeley ファイルシステムの設計原則に従って、商用グレードのファイルシステムとして根本から設計されました。
Ext2 は、GB 単位の最大ファイル サイズと TB 単位のファイル システム サイズを提供し、1990 年代のファイル システム界の大手リーグでの地位を確固たるものにしました。すぐに Linux カーネルと MINIX の両方で広く使用されるようになり、サードパーティのモジュールによって MacOS と Windows でも利用できるようになりました。
しかし、解決すべき問題がまだいくつかあります。ext2 ファイル システムは、1990 年代のほとんどのファイル システムと同様に、データがディスクに書き込まれている間にシステムがクラッシュしたり電源が落ちたりすると、壊滅的なデータ破損の影響を受けやすくなります。時間が経つにつれて、断片化 (1 つのファイルが複数の場所に保存され、回転ディスク全体に物理的に分散される) による深刻なパフォーマンス低下も発生しました。
これらの問題にもかかわらず、ext2 は現在でもいくつかの特殊なケースで使用されています。最も一般的なのは、ポータブル USB ドライブのファイル システム形式としてです。

拡張子3

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

1990 年代半ばの Packard Bell コンピュータ、Spacekid、CC0

ほとんどの場合、ext2 は Linux ディストリビューションで十分に機能しましたが、当時の FAT、FAT32、HFS などのファイルシステムと同様に、停電が発生した場合に壊滅的な破損が発生する傾向がありました。データがファイル システムに書き込まれている間に電源が失われると、不整合状態 (半分完了し、半分完了していない状態) のままになる可能性があります。これにより、保存されているファイルとは無関係の多数のファイルが失われたり破損したり、ファイル システム全体がマウントできなくなる可能性があります。
ext3 や、Microsoft の NTFS など 1990 年代後半のその他のファイル システムでは、ジャーナリングを使用してこの問題に対処しています。ジャーナルは、トランザクション内で書き込みが保存されるディスク上の特別に割り当てられた領域です。そのトランザクションがディスク書き込みを完了すると、ジャーナル内のデータはファイル システム自体にコミットされます。この操作がコミットされる前にシステムがクラッシュした場合、再起動されたシステムはそれを不完全なトランザクションとして認識し、何も起こらなかったかのようにロールバックします。つまり、進行中のファイルは失われる可能性がありますが、ファイル システム自体は一貫性が保たれ、他のすべてのデータは安全です。
Linux カーネルでは、ext3 ファイル システムを使用して、ジャーナル、順序付き、ライトバックの 3 つのレベルのログ記録が実装されています。
ジャーナリングはリスクが最も低いモードで、データとメタデータはファイル システムにコミットされる前にジャーナルに書き込まれます。これにより、書き込まれるファイルがファイル システム全体と一貫していることが保証されますが、パフォーマンスは大幅に低下します。
シーケンシャルは、ほとんどの Linux ディストリビューションのデフォルト モードです。シーケンシャル モードでは、メタデータがジャーナルに書き込まれ、データがファイル システムに直接コミットされます。名前が示すように、ここでの操作の順序は固定されています。最初にメタデータがログにコミットされ、次にデータがファイル システムに書き込まれ、その後ログ内の関連するメタデータがファイル システムに更新されます。これにより、クラッシュが発生した場合でも、不完全な書き込みに関連付けられたメタデータがジャーナル内に残り、ジャーナルをロールバックするときにファイル システムが不完全な書き込みトランザクションをクリーンアップできるようになります。シーケンシャル モードでは、システム クラッシュにより、クラッシュ中にアクティブに書き込まれたファイルにエラーが発生する可能性がありますが、ファイル システム自体、およびアクティブに書き込まれなかったファイルは安全であることが保証されます。
ライトバックは 3 番目のモードであり、最も安全性の低いログ モードです。ライトバック モードでは、シーケンシャル モードと同様に、メタデータは記録されますが、データは記録されません。シーケンシャル モードとは異なり、メタデータとデータはどちらも、最適なパフォーマンスを実現する任意の順序で書き込むことができます。これによりパフォーマンスは大幅に向上しますが、安全性は大幅に低下します。ライトバック モードではファイル システム自体の安全性は保証されますが、クラッシュや破損の前に書き込まれたファイルは簡単に失われたり破損したりする可能性があります。
以前の ext2 と同様に、ext3 は 16 ビットの内部アドレス指定を使用します。つまり、最大サイズが 16 TiB のファイル システムでは、4K ブロック サイズの ext3 で処理できる最大ファイル サイズは 2 TiB になります。

拡張子4

Ext4 は、2006 年に Theodore Ts'o (当時の ext3 の主要開発者) によってリリースされ、2 年後に 2.6.28 カーネル バージョンで Linux メインラインに追加されました。
Ts'o 氏は、ext4 を ext3 を大幅に拡張しながらも依然として古いテクノロジに依存している暫定的なテクノロジであると説明しています。彼は、ext4 は最終的には真の次世代ファイルシステムに置き換えられると予測しています。

Dell Precision 380 ワークステーション、ランス・フィッシャー、CC BY-SA 2.0

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

ext4 と ext3

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

大規模ファイルシステム

ext3 ファイルシステムは 32 ビットのアドレス指定を使用するため、2 TiB のファイル サイズと 16 TiB のファイルシステム サイズしかサポートされません (これは 4 KiB のブロック サイズを想定していますが、一部の ext3 ファイルシステムではより小さなブロック サイズが使用されるため、さらに制限されます)。
Ext4 は 48 ビットの内部アドレス指定を使用し、理論的にはファイル システム上に最大 16 TiB のサイズのファイルを割り当てることができます。ファイル システムのサイズは最大 1,000,000 TiB (1 EiB) です。初期の ext4 実装では、一部のユーザー空間プログラムによってファイルシステムの最大サイズが 16 TiB に制限されていましたが、2011 年現在、e2fsprogs は 16 TiB を超える ext4 ファイルシステムを直接サポートしています。たとえば、Red Hat Enterprise Linux は契約上、最大 50 TiB の ext4 ファイル システムのみをサポートしており、ext4 ボリュームは 100 TiB 以下にすることを推奨しています。

配分方法の改善

ext4 では、ストレージ ブロックがディスクに書き込まれる前に割り当てられる方法にいくつかの改善が加えられ、読み取りと書き込みのパフォーマンスが大幅に向上します。

範囲セクション

エクステントは、一度に予約してアドレス指定できる、連続した物理ブロックのシリーズです (ブロック サイズが 4 KiB の場合、最大 128 MiB)。エクステントを使用すると、特定のファイルに必要な inode の数を削減し、断片化を大幅に削減して、大きなファイルを書き込むときのパフォーマンスを向上させることができます。

マルチブロック割り当て

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

永続的な事前割り当て

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

遅延割り当て

これは興味深く、議論の余地のある機能です。遅延割り当てにより、ext4 は、データをディスクにコミットする準備ができるまで、データが書き込まれる実際のブロックの割り当てを待機できます。 (対照的に、ext3 は、データが書き込みキャッシュに書き込まれている場合でも、ブロックを即座に割り当てます。)
データがキャッシュに蓄積されるにつれてブロックの割り当てを遅らせると、ファイル システムはブロックの割り当て方法についてより適切な選択を行えるようになり、断片化 (書き込み時、およびその後の読み取り時) が軽減され、パフォーマンスが大幅に向上します。しかし残念なことに、fsync() メソッドを明示的に呼び出していないプログラム (プログラマがデータが完全にディスクにフラッシュされることを保証したい場合) では、データが失われる可能性が高くなります。
プログラムがファイルを完全に書き換えるとします。

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

古いファイル システムでは、close(fd); だけでファイルの内容がディスクにフラッシュされることが保証されます。厳密に言えば書き込みはトランザクションではありませんが、ファイルが閉じられた後にクラッシュが発生した場合、データが失われるリスクがわずかにあります。
書き込みが失敗した場合 (プログラムのバグ、ディスクのエラー、停電などにより)、元のファイルと新しいバージョンのファイルの両方でデータが失われたり破損したりする可能性があります。ファイルの書き込み中に他のプロセスがそのファイルにアクセスすると、破損したバージョンが表示されます。他のプロセスがファイルを開いており、その内容を変更したくない場合 (たとえば、複数の実行中のプログラムにマップされている共有ライブラリなど)。これらのプロセスはクラッシュする可能性があります。
これらの問題を回避するために、一部のプログラマーは O_TRUNC の使用を完全に避けます。代わりに、新しいファイルに書き込み、それを閉じてから、古いファイル名に変更する可能性があります。

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

遅延割り当てのないファイル システムでは、これは上記の潜在的な破損やクラッシュの問題を回避するのに十分です。rename() はアトミック操作であるため、クラッシュによって中断されることはなく、実行中のプログラムは引き続き古いファイルを参照します。これで、リンクされていないバージョンのファイルに必要なのは、ファイルへの開いているファイル ハンドルのみになります。しかし、ext4 の遅延割り当てにより書き込みが遅延され、順序が変更されるため、newfile の内容が実際にディスクに書き込まれる前に rename("newfile", "file") が実行され、並列でファイルの不良バージョンが再度取得されるという問題が発生します。
これを緩和するために、Linux カーネル (バージョン 2.6.30 以降) は、これらの一般的なコード ケースを検出し、即時の割り当てを強制しようとします。これにより、データ損失の可能性は軽減されますが、完全に防止することはできません。また、新しいファイルには役立ちません。開発者の方は注意してください: データがすぐにディスクに書き込まれることを保証する唯一の方法は、fsync() を正しく呼び出すことです。

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

ext3 ではサブディレクトリの数が 32,000 に制限されていますが、ext4 ではサブディレクトリの数に制限はありません。カーネル バージョン 2.6.23 以降、ext4 は HTree インデックスを使用して、多数のサブディレクトリによるパフォーマンスの低下を軽減します。

ログ検証

Ext3 はチェックサム ログを実行しないため、カーネルの直接制御外のディスクや独自のキャッシュを持つコントローラ デバイスでは問題が発生します。独自のキャッシュを持つコントローラまたはディスクの書き込み順序が乱れると、ext3 のジャーナル トランザクションの順序が乱れ、クラッシュ中 (またはクラッシュ前のしばらく) に書き込まれたファイルが破損する可能性があります。
理論的には、この問題は書き込みバリアを使用して解決できます。ファイルシステムをマウントするときに、マウント オプションで barrier=1 を設定すると、デバイスは基礎となるハードウェアに至るまで fsync を忠実に実行します。実際には、ストレージ デバイスとコントローラは書き込みバリアを尊重しないことが多く、パフォーマンス (および競合他社と比較したパフォーマンス ベンチマーク) は向上しますが、防止すべきデータ破損の可能性が高くなります。
ジャーナルのチェックサムを計算すると、クラッシュ後にファイル システムを初めてマウントしたときに、そのエントリの一部が無効であるか、順序が正しくないことが分かります。これにより、一部のストレージ デバイスが書き込みバリアを偽装したり、書き込みバリアに従わなかったりする場合でも、部分的または順序どおりでないログ エントリをロールバックしてファイル システムをさらに破損するエラーを回避できます。

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

ext3 では、fsck が呼び出されると、削除されたファイルや空のファイルも含め、ファイルシステム全体がチェックされます。対照的に、ext4 は未割り当てのブロックとセクターを inode テーブルにマークし、fsck がそれらを完全にスキップできるようにします。これにより、ほとんどのファイルシステムで fsck を実行するのにかかる時間が大幅に短縮され、カーネル 2.6.24 で実装されています。

タイムスタンプの改善

ext3 は 1 秒単位のタイムスタンプを提供します。ほとんどの目的には十分ですが、ミッションクリティカルなアプリケーションでは、より厳密なタイミング制御が必要になることがよくあります。 ext4 はナノ秒単位のタイムスタンプを提供することで、エンタープライズ、科学、ミッションクリティカルなアプリケーションに役立ちます。
ext3 ファイル システムでは、2038 年 1 月 18 日以降の日付を保存するのに十分なビットが提供されません。 ext4 はここで 2 ビットを追加し、Unix エポックを 408 年延長します。あなたがこれを西暦 2446 年に読んでいるなら、より優れたファイル システムに移行している可能性が高いです。あなたがまだ 1970 年 1 月 1 日 00:00 (UTC) から時間を計測しているなら、私は死後も安らかに眠ることができるでしょう。

オンラインデフラグ

ext2 も ext3 も、オンライン デフラグ (つまり、マウントされているファイル システムのデフラグ) を直接サポートしていません。 ext2 には e2defrag というユーティリティが付属しており、その名前が示すとおり、ファイルシステムがマウントされていないときにオフラインで実行する必要があります。 (明らかに、これはルートファイルシステムにとって非常に問題です。) ext3 では状況はさらに悪く、ext3 は ext2 よりも深刻な断片化の影響を受けにくいものの、ext3 ファイルシステムで e2defrag を実行すると、壊滅的な破損やデータ損失が発生する可能性があります。
ext3 はもともと「断片化の影響を受けない」と考えられていましたが、同じファイルへの大規模な並列書き込みプロセス (BitTorrent など) を使用すると、必ずしもそうではないことが明らかになります。 Shake などの一部のユーザー空間のトリックや回避策は、何らかの方法でこの問題に対処しますが、実際のファイルシステム対応のカーネルレベルのデフラグ プロセスよりも遅く、さまざまな点で満足度が低くなります。
ext4 は、オンライン、カーネル モード、ファイル システム対応、ブロック レベルおよびエクステント レベルのデフラグ ユーティリティである e4defrag を使用してこの問題を解決します。

進行中の ext4 開発

ext4 は、モンティ・パイソンの疫病感染者がかつて言ったように、「私はまだ死んでない！」 主任開発者は、真の次世代ファイルシステムへの道の暫定的な手段に過ぎないと考えているが、当分の間、ルートファイルシステムとして導入できる候補は存在しないだろう（技術的またはライセンス上の問題のため）。
メタデータ チェックサム、ファーストクラスのクォータ サポート、大きな割り当てブロックなど、ext4 の将来のバージョンで開発される重要な機能がまだいくつかあります。

メタデータチェックサム

ext4 には冗長スーパーブロックがあるため、ファイル システムはその中のメタデータを検証し、プライマリ スーパーブロックが破損していて予備ブロックを使用する必要があるかどうかを自ら判断できるようになります。チェックサムなしで破損したスーパーブロックから回復することは可能ですが、ユーザーはまず破損していることを認識し、別の方法を使用してファイルシステムを手動でマウントする必要があります。破損したプライマリ スーパーブロックを持つファイルシステムを読み取り/書き込みでマウントすると、場合によっては、経験豊富なユーザーでも回避できないさらなる損傷が発生する可能性があるため、これも完璧な解決策ではありません。
Btrfs や ZFS などの次世代ファイルシステムによって提供される非常に強力なブロックごとのチェックサムと比較すると、ext4 のメタデータ チェックサムは非常に弱いです。しかし、何もしないよりはましです。すべてを検証するのは簡単そうに聞こえますが! -- 実際、チェックサムをファイル システムと結合する際にはいくつかの重大な課題があります。詳細については設計ドキュメントを参照してください。

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

待って、割り当て？ ！ ext2 がリリースされた日からこれを使用しました。はい、でもそれはいつも後から付け加えられたもので、いつもばかげたものでした。ここで詳しく説明する価値はないかもしれませんが、設計ドキュメントでは、クォータをユーザー空間からカーネルに移動して、より正確かつ効率的に適用する方法が示されています。

大きな割り当てブロック

時間が経つにつれて、これらの厄介なストレージ システムはどんどん大きくなります。一部の SSD ではすでに 8K のハードウェア ブロック サイズが使用されているため、ext4 の現在の 4K ブロックの制限はますます厳しくなっています。ストレージ ブロックを大きくすると、断片化が大幅に減少し、パフォーマンスが向上しますが、「スラック」スペース (ファイルを格納するためにブロックの一部またはファイルの最後のブロックのみが必要な場合に残るスペース) が増加します。詳細な手順は設計ドキュメントに記載されています。

ext4 の実際的な制限

ext4 は堅牢で安定したファイルシステムです。最近ではほとんどの人がこれをルートファイルシステムとして使用していますが、すべてのニーズに対応できるわけではありません。現時点でも将来的にも、期待すべきではない事柄について簡単にお話ししましょう。

ext4 は最大 1 EiB (1,000,000 TiB に相当) のサイズのデータ​​を処理できますが、実際にそうすることはお勧めしません。より多くのブロックのアドレスを記憶できることに加えて、スケールの問題もあります。そして現在、ext4 は 50 ～ 100 TiB を超えるデータを処理できません (おそらく今後も処理できないでしょう)。

Ext4 もデータの整合性を保証するには不十分です。ジャーナリングは ext3 の時代では大きな進歩でしたが、データ破損の一般的な原因の多くをカバーしていませんでした。ハードウェアの故障、宇宙線の影響 (本当にそうです)、または単に時間の経過によるデータの劣化などにより、ディスク上のデータがすでに破損している場合、ext4 はこの破損を検出または修復できません。

上記の 2 つの点に基づくと、ext4 は単なる純粋なファイル システムであり、ストレージ ボリューム マネージャーではありません。つまり、複数のディスク（つまりパリティまたは冗長性）がある場合でも、理論的には ext4 から破損したデータを回復できますが、それを有利に利用することが役立つかどうかを知る方法はありません。自動破損検出および修復機能を失うことなく、ファイル システムとストレージ ボリューム管理システムを異なるレイヤーに分離することは理論的には可能ですが、これは現在のストレージ システムの設計方法ではなく、新しい設計に大きな課題をもたらすことになります。

代替ファイルシステム

始める前に、警告しておきます。代替ファイルシステムは組み込まれておらず、メインライン カーネルの一部として直接サポートされていないので、十分注意してください。

ファイルシステムが安全であっても、カーネルのアップグレード中に何か問題が発生した場合、それをルートファイルシステムとして使用するのは非常に危険です。 chroot 経由で代替メディア ブートを使用する正当な理由がない場合は、カーネル モジュール、grub 構成、DKMS に注意してください。重要なシステムで予約済みのルート ファイルを削除しないでください。

ディストリビューションが直接サポートしていないファイルシステムを使用する正当な理由がある場合もありますが、その場合は、システムが起動して実行された後にインストールすることを強くお勧めします。 (たとえば、ext4 ルート ファイルシステムを使用している場合でも、ほとんどのデータは ZFS または Btrfs プールに保存されます。)

.XFS の

XFS は、メインライン Linux の非 ext ファイル システムと同じステータスを持ちます。これは、2001 年から Linux カーネルに組み込まれている 64 ビットのジャーナリング ファイル システムであり、大規模なファイル システムで高いパフォーマンスと高い同時実行性 (つまり、多数のプロセスが同時にファイル システムに書き込む) を実現します。
RHEL 7 以降、XFS は Red Hat Enterprise Linux のデフォルトのファイル システムになります。家庭や小規模ビジネスユーザーにとってはまだいくつかの欠点があります。最も顕著なのは、既存の XFS ファイルシステムのサイズを変更するのは非常に面倒なため、別のファイルシステムを作成してデータをコピーするだけでは意味がないことです。
XFS は安定しており、パフォーマンスも優れていますが、50 TiB を超えるファイルシステムなど、ext4 の特定の問題を解決しない限り、デフォルト以外 (RHEL7 など) で使用することを推奨するほど、ext4 との具体的な最終用途の違いはありません。
XFS は、ZFS、Btrfs、さらには WAFL (独自の SAN ファイル システム) の「次世代」ファイル システムではありません。 ext4 と同様に、より良い方法が出てくるまでの暫定的な対策として考えるべきです。

ZFS

Sun Microsystems によって開発された ZFS は、理論的に非常に大規模なストレージ システムに対応できるため、1 兆ギガバイトに相当するゼタバイトにちなんで名付けられました。
真の次世代ファイルシステムである ZFS は、ボリューム管理 (単一のファイルシステムで複数の個別のストレージデバイスを処理する機能)、ブロックレベルの暗号化チェックサム (データ破損を非常に高い精度で検出可能)、自動破損修復 (冗長ストレージまたはパリティストレージが利用可能な場合)、高速非同期増分レプリケーション、インライン圧縮など、さまざまな機能を提供します。
Linux ユーザーの観点から見ると、ZFS の最大の問題はライセンスの問題です。 ZFS ライセンスは CDDL であり、GPL と競合する半許容ライセンスです。 Linux カーネルで ZFS を使用することの重要性については多くの論争があり、「GPL 違反である」、「CDDL 違反である」、「法廷でテストされていないのでまったく問題ない」などさまざまな議論があります。最も注目すべきは、Canonical が 2016 年から ZFS コードをデフォルトのカーネルにインライン化しており、これまで法的な異議申し立ては行われていないことです。
現時点では、熱心な ZFS ユーザーであっても、Linux ルート ファイルシステムとして ZFS を使用することはお勧めしません。 Linux で ZFS を活用したい場合は、ext4 で小さなルート ファイルシステムを設定し、残りのストレージには ZFS を使用して、データ、アプリケーションなどをそこに保存します。ただし、ディストリビューションが ZFS ルートを明示的にサポートするまでは、ルート パーティションを ext4 上に保持します。

Btrfs

Btrfs (B-Tree Filesystem の略で、「バター」と発音されることが多い) は、2007 年に Oracle に在籍していた Chris Mason によってリリースされました。 Btrfs は、複数のデバイス管理、ブロックごとのチェックサム、非同期レプリケーション、インライン圧縮などを提供し、ZFS とほぼ同じ目標を実現することを目指しています。
2018 年現在、Btrfs はかなり安定しており、標準の単一ディスク ファイルシステムとして使用できますが、ボリューム マネージャーとしてはおそらく依存しないほうがよいでしょう。多くの一般的な使用例において、ext4、XFS、ZFS と比較してパフォーマンスに重大な問題があり、レプリケーション、マルチディスク トポロジ、スナップショット管理などの次世代機能が非常に多いため、その結果は壊滅的なパフォーマンス低下から実際のデータ損失まで多岐にわたる可能性があります。
Btrfs の継続的なステータスは議論の的となっています。SUSE Enterprise Linux は 2015 年にこれをデフォルトのファイルシステムとして採用しましたが、Red Hat は 2017 年に RHEL 7.4 以降では Btrfs をサポートしないと発表しました。この製品は、ZFS のようなマルチディスク ボリューム マネージャーではなく、単一ディスク ファイル システムとして使用される Btrfs 展開をサポートしていることに注目する価値があるかもしれません。Synology もストレージ デバイスで Btrfs を使用していますが、ディスクの管理には従来の Linux カーネル RAID (mdraid) の上に階層化されています。

以下に、ext~ext4 の概要、機能、利点を簡単に示します。

要約する

以上がこの記事の全内容です。この記事の内容が皆様の勉強や仕事に何らかの参考学習価値をもたらすことを願います。123WORDPRESS.COM をご愛顧いただき、誠にありがとうございます。これについてもっと知りたい場合は、次のリンクをご覧ください。