自作の NAS アレイに ZFS を使用することを考えます。Ubuntu Server 10.04 マシンの raidz に 4 台の HDD を配置する予定です。
データの保存時にスナップショット機能と重複排除機能を使用したいと思います。マシンは N ワイヤレス ネットワーク経由でアクセスされるため、速度についてはあまり心配していません。おそらくこれがボトルネックになるでしょう。
では、そのような（または同様の）構成で zfs-fuse 0.6.9 を使用した実践的な経験のある方はいらっしゃいますか?
答え1
自宅の NAS (debian lenny) に 500GB ドライブを 2 台、zfs-fuse ミラー セットアップでインストールしています。約 6 か月間稼働していますが、問題は発生していません。詳細ここ私のブログで。
答え2
現在、ネイティブ Linux ポートZFS の。私は最近になってこのことを知ったので、まだテストする機会がありません。しかし、現在も活発に開発が進められており、これは良い兆候です。カーネル モジュールとツールを自分でコンパイルしなければならないことに怖気付かない限り、試してみる価値はあるでしょう。
動作させることができれば、間違いなく zfs-fuse よりもはるかに優れたパフォーマンスを発揮します。
答え3
このスレッドは古いものだとわかっていますが、それ以来状況はかなり変化しました。(たとえば、ZFS-FUSE の状態とカーネル内オプション、議論の余地のある「オープン」Solaris の消滅など)
まず、ZFSのカーネルポートは必然的にZFS-FUSE よりも「間違いなく」はるかに優れたパフォーマンスを発揮します。この回答は、FUSE ファイルシステムのパフォーマンスはカーネル内よりも常に劣るという一般的な誤解を反映しているようです。(ご存じない方のために簡単に説明すると、理論上はカーネル ファイルシステムの方がパフォーマンスが優れています。他の条件が同じであれば、カーネル ファイルシステムの方がパフォーマンスは優れています。ただし、カーネルとユーザー空間よりもパフォーマンスに影響を与える要因は他にもたくさんあります。) ただし、ZFS-FUSE の場合、ベンチマークによると、ネイティブ ZFS (または BTRFS) よりも大幅に遅いケースがあるようです。ただし、私の用途では問題ありません。
Ubuntu には現在、PPA リポジトリ システムを通じて「ubuntu-zfs」パッケージがあります。これはネイティブの zfs-on-linux プロジェクトの優れたパッケージングと自動モジュール構築です。これはカーネル空間で実行され、現在 zfs-fuse よりも高い zpool バージョンをサポートしています。
私はかつて、20TB の冗長性のある大型サーバーで OpenSolaris を使用していましたが、現在は Oracle Solaris 11 を使用しています。Solaris には、いくつかの重大な問題と課題があります (特に、旧式の UNIX ではなく Linux の構成と管理に慣れている場合)。また、ハードウェア管理やその他の構成インターフェイスの多くが OS バージョン間、さらには更新間で大幅に変更されているため、(次のバージョンにアップグレードする前に 1 つのバージョンを最終的にマスターした後でも) 非常にイライラする変更対象になることがよくあります。ただし、適切な (互換性のある) ハードウェアと、変更、学習、調整に対する多大な忍耐があれば、ファイル システムとしては素晴らしい選択肢になる可能性があります。
もう 1 つアドバイスがあります。組み込みの CIFS サポートは使用しないでください。Samba を使用してください。組み込みのサポートは壊れており、すぐに使用できる状態にならない可能性があります。最後に確認したところ、Samba を使用しているエンタープライズ インストールは多数ありましたが、権限管理の難しさから、CIFS を使用しているものは 1 つもありませんでした。
私も毎日 Ubuntu で ZFS-FUSE を使用しています (個人のワークステーション)。ZFS-FUSE は堅牢で素晴らしいソリューションです。ZFS-FUSE に関して特に考えられる問題点は次のとおりです。
ZIL (書き込みキャッシュ) を無効にすることはできません。少なくとも、ソース コードにフラグを設定して自分でコンパイルしない限りは。ちなみに、よくある誤解に反して、ZIL を無効にしてもクラッシュ時にプールが失われることはありません。その時点で書き込まれていたものがすべて失われるだけです。これは、ほとんどのファイル システムと変わりません。これは、多くのミッション クリティカルなサーバー シナリオには理想的ではないかもしれませんが (その場合は、ネイティブの Oracle Solaris を使用する必要があるでしょう)、ほとんどのワークステーション/個人の使用ケースでは通常、非常に価値のあるトレードオフです。小規模なセットアップでは、ZIL は書き込みパフォーマンスの大きな問題になる可能性があります。これは、デフォルトでキャッシュがプール自体に分散されるためです。パリティ ストライプ セットアップ (RAIDZx) の場合は特に、かなり遅くなる可能性があります。Oracle Solaris では、無効にするのは簡単です。プールの「同期」プロパティだと思います。(ネイティブの Linux カーネル バージョンで簡単に無効にできるかどうかはわかりません。)
また、ZFS-FUSE では、zpool のバージョンが、より新しいバージョンのより優れたプール回復オプションをサポートするほど高くないため、書き込みキャッシュを 1 つ以上の SSD または RAM ドライブなどにオフロードすることにした場合は、注意してください。(そして、常にミラーリングしてください!) ZIL が失われると、ほぼ確実にプール全体も失われます。(これは、OpenSolaris で私に起こった悲惨な出来事です。) Oracle Solaris のより新しい zpool バージョンでは、この問題が軽減されています。カーネル レベルの Linux ポートにその軽減策が組み込まれているかどうかは、私には判断できないようです。
また、その人が議論にスパムしているように見える「ZFS ARC バグ」の警告は無視しても問題ありません。私のサーバーは、世界中の無数の実稼働サーバーと同様に、激しい負荷を受けていますが、そのようなことは一度も経験したことがありません。
個人的には、Solaris は大嫌いですが、ZFS は素晴らしいです。今ではその機能に頼るようになり、ZFS なしでは生きていけません。Windows ノートブックでも使用しています (複雑ですが非常に信頼性の高い仮想化ソリューションと、蓋にマジックテープで留めた USB ドライブを介して)。
編集: 明確さ、関連性、および ZFS-FUSE のパフォーマンス制限を認識するために、いくつかの小さな編集を行いました。
答え4
私はプールを OpenSolaris に移行する前に、ほぼ 1 年間 Ubuntu で ZFS-FUSE を問題なく実行していました。とはいえ、マルチ TB プールでの重複排除のメモリ要件は、自宅の Linux サーバーのメモリを超える可能性があります。重複排除テーブルが ARC (プライマリ メモリ キャッシュ) からあふれ出ると、L2ARC 用の SSD を用意してすぐに使用できるようにしておかない限り、重複排除のパフォーマンスはひどくなります。重複排除テーブルがメモリ内にないと、多くの操作が信じられないほど遅くなる可能性があります (ファイルのディレクトリの削除、スナップショットの削除など)。スナップショットは重複排除なしで機能し、それ自体にはほとんどオーバーヘッドがないため、大量の冗長データを保存していて、8～16 GB の RAM や SSD を投入して問題を解決しない限り、重複排除はスキップします。