Ext4対XFS対Btrfs対ZFS NAS
私の使用例：M.2 SSDにUbuntu Server 18.04がインストールされています。ストレージとして追加したい4TB HDDがあります。これは主に大きなメディアファイルとバックアップ用であるため、頻繁に書き込まれることはありません。
この使用例に最適なファイルシステムはどれですか？
私の主要な候補は、Ext3/4、XFS、Btrfs、およびZFSです（別のものについては自由に議論してください）。
「最高のファイルシステムは何ですか？」という質問はしていません。「最高」というようなものはありません。私は、ファイルシステムは、この使用例に最も適している可能性があります。含めてみてください：
- 欠点やリスクはありますか？停電が発生すると、XFSがデータを破壊する可能性があると聞きました。 ECC RAMのないZFSと同じです。
- データを失うことなく、後でRAID-1を追加することは可能ですか？現在、別のハードドライブに十分な資金がありません（外付けドライブにそれを使用しました。RAIDはバックアップの代わりにはなりません）が、後で追加する可能性があります。これは要件ではなく、ニースかもしれません。
- 読み取り/書き込みパフォーマンスとは何ですか？ Btrfsはおそらく私のニーズのほとんどに適合しますが、Phoronixベンチマークでは非常に低速です。 XFSは素晴らしいパフォーマンスを発揮しますが、データが失われる可能性があると聞きました。
アドバイスありがとうございます。
私は通常、次の2つのファイルシステムのいずれかを使用します。
CoW（またはデータストアが既にCoWファイルシステム上にある仮想マシン）でうまく機能しないもの、または非常に高速なダイレクトI/Oが必要な場合のXFS。
その他のZFS。
あなたのユースケースでは、特にUbuntu 18.04がすでに出荷していることを考えると、私はZFSを使用します。既存のデバイスに別のミラーレッグを簡単に取り付けることができるため、ZFSはこの要件に非常によく適合します。たとえば、ディスクにnvme0p1という名前を付けます。
zpool create tank /dev/nvme0p1単一のvdevプールを作成します。zpool attach tank <newdev> /dev/nvme0p1はミラーリングを有効にします。
何らかの理由でZFSを使用できない、または使用できない場合は、MDRAIDとXFSが役に立ちます。
mdadm --create /dev/md200 -l raid1 -n 2 /dev/nvme0p1 missingは、足のないRAID1アレイを作成します（＃1を参照）。mdadm --manage /dev/md200 --add <newdev>は新しいミラーレッグをアタッチします（完全なRAID1を形成し、＃2を参照）
配列を作成したら、mkfs.xfsを使用してXFSでフォーマットできます。
パフォーマンスと回復力はどちらも劣るので、BTRFSを使用することをしないことをお勧めします。たとえば、 Debian wiki から：
現在（2019-07-07、linux≤5.1.16）、2つのディスクのraid1プロファイルが2回目に劣化状態でマウントされたときに永久に読み取り専用になるバグがあります。たとえば、欠落/破損/ SATAリンクリセットディスク
また、BTRFS（read：Synology）を使用する商用NASベンダーは独自の統合RAID機能を使用せず、実績のあるLinux MDRAIDレイヤーを使用することに注意してください。
EDIT：一部の人は、XFSがデータ損失を起こしやすいと言っていますが、これは単に正しくありません。さて、ext3と比較すると、XFS（および遅延割り当てをサポートする他のファイルシステム）は、制御されていない電源オフの場合に、より多くの非同期データを失う可能性があります。ただし、同期されたデータ（つまり、重要な書き込み）は100％安全です。さらに、XFSデータ損失を悪化させる特定のバグ 10年以上前に修正されました 。そのバグは別として、any遅延割り当て準備ファイルシステム（ext4およびbtrfsを含む）は、かなりの数または非同期データを失うコントローラの電源がオフの場合。
Ext4と比較して、XFSには無制限のiノード割り当て、高度な割り当てヒント（必要な場合）、最近のバージョンではreflinkサポートがあります（ただし、Ubuntu 18.04で明示的に有効にする必要があります。 mkfs.xfsのマニュアルページ）を参照してください 追加情報）
1：デバイスが見つからない/proc/mdstatファイルの例：
Personalities : [raid1]
md200 : active raid1 loop0[0]
65408 blocks super 1.2 [2/1] [U_]
unused devices: <none>
2：2番目のデバイスを追加した後の/proc/mdstatファイル
Personalities : [raid1]
md200 : active raid1 loop1[2] loop0[0]
65408 blocks super 1.2 [2/2] [UU]
unused devices: <none>
これは、serverfaultよりも superuser の質問に似ていますが、一部のアイデアはこのサイトにも有効であるため、いくつかの質問に答えます。
- XFSは停電を好まないという評判があります。それ以来多くのことが起こっており、RedHatやOracleなどが最近ではデフォルトのファイルシステムとして使用しているため、これが以前よりもはるかに小さな問題であるとしても、驚くことはありません。特に適切なバックアップポリシーを使用している場合、このファイルシステムを使用すると速度が向上すると考えられるユースケースであれば、考えられるリスクに値する可能性があります。
- ECCなしのZFS RAMには依然として非常に優れた機能がありますが、不良データのいくつかのインスタンスをキャッチしないリスクがあります。ECSなしのZFSを数年間、自宅と同じような設定で実行しました説明し、明らかなデータ損失を経験したことはありませんでしたが、重要なデータをそのボリュームに正確に保存していませんでした。それ以降、適切なサーバーハードウェアに移行し、実際にストレージを重要なものに実際に使用することについてはるかに快適に感じています。
- ZFSを使用すると、単一のディスクプールにディスクを追加してミラーを作成できるようになります。私は実際には試していませんが、 duckduckgo をチェックすると、複数の検索結果が表示され、成功したと主張します。他のシステムについてはわかりませんが、ファイルシステムの下にある種のボリュームマネージャがある限り、単一のディスクからRAID1に移行することは簡単です。
- CoWベースのファイルシステム（zfs、btrfs）は、機能の豊富でないシステムよりも低速であり、十分に強力なハードウェアがそれらをサポートしていることにより依存しています。
企業の設定の場合と同様に、パフォーマンスと機能を直接体験するために、予想される負荷でベンチマークを実行するのに時間をかけることは間違いありません。
十分な理由がない限り、問題のオペレーティングシステムがデフォルトとして提案したジャーナリングファイルシステムを使用します。前回、ext4であるUbuntuを確認しました。
理由は簡単です。デフォルトが最もよく使用されるものであるため、バグが発見および修正される可能性が最も高いです。あなたが言及するファイルシステム間の違いは、毎日の軽い使用において多くを意味することはほとんどありません。パフォーマンスが非常に重要な場合は、オペレーティングシステムにキャッシュする余地を増やすために、代わりにメモリを増やすことを検討してください。
とは言っても、オペレーティングシステム全体でドライブを使用する場合は、2つ取得するか、少なくとも1つを2つの物理パーティションに分割し、メディアがあるものでNTFSまたはexFATを使用することをお勧めします。
長期にわたってデータの整合性を重視する場合は、zfsまたはbtrfsをお勧めします。
私が理解しているのは、これらの2つだけが、データをスクラブしてビットの腐敗を探し、修正できる可能性があるということです。
私はzfsにはあまり詳しくありませんが、btrfsを約5〜6年間実行しています。 RAID1で実行しており、毎週スクラブジョブを行っています。 （注：ミラーリングされていない場合、スクラブは、修復するのではなく、それらの不良ブロックをマークするだけです！）
私が持っていた唯一の問題は、エクステントが自動的に解放されず、ディスクがいっぱいになったが実際にはいっぱいにならなかったというバグがあったことです。
どちらにも圧縮と重複排除がありますが、btrfsの重複排除はオフラインです-これを好む人もいます。
チェックする別のリソースは、この最近の投稿で Hacker News に到達しました： Btrfsの5年間
注：XFS/ext4スクラブに向けて 一部の作業 があるようです
実際のミラーがなくても、mdadmが完了したミラーであるXFS形式のファイルシステムを作成できます。
3つのミラーがあり、2つは存在しないミラーとしてパーティションを作成します。後で2つの欠落しているものを追加できます。