NetBSDでのZFSはソースが古く、 メンテナンスする人がまったく不在なので、 最新コードベースを保守する技術がないならばNetBSDでのZFSの運用はおすすめできません。 ZFSでNASを構築する場合は、 メンテナの存在する(開発が行われている)FreeBSDの採用を検討してください。 NetBSDでZFSを扱う場合は、そこが無人の荒野であることを理解してからにしましょう。
NetBSDのZFSコードは古いので、 当時知られていなかった致命的なバグがそのまま放置されていると考えらえます。 ストレージを試したり設計したりする場合は、 そこが未修正のバグの山であることを考慮してください。 このことは、 NetBSDでZFSのバグを発見・修正しても車輪の再発明になるだろう、 ということを言っています。
NetBSDでZFSのメンテナンスを志す者が最初にしなければならないことは、 バグの発見と修正ではありません。 ZFSの最新コードに追いつかせる(再移植する)ことです。
NetBSD ZFSの場合、zpool statusは機能しません。 raidzやmirrorを組んでもステータスは確認できないということです。 実運用はあきらめて、素直にFreeBSD等他のOSを当たってください。
2016年現在においてZFS世界から取り残されているNetBSD ZFSのコードベースは、 ディレクトリ名からも推測される通りOpenSolaris時代のものです。 Sunを買収したOracleがクローズドソース方針に転換してからというもの OpenSolarisは既に瓦解してZFSコードベースはOpenZFSにフォークしており、 都合の悪いことにOpenZFSにはセントラルリポジトリと呼ぶべきものが存在しません。 OpenSolarisなきあとの現在では、 コードベースが取り込まれたそれぞれのOSプロジェクトにおいて個別に開発 (分化と進化) が進められています。
OpenSolarisのコードを読めばよいという時代は既に終わってしまいました。 ZFSのコードを更新する場合、 どこからどのコードをどのようなディレクトリ構成で持ってくるか、 ということが議論となることが予想されます。 これら時代背景は、 NetBSD ZFSコードベースの更新を困難なものにしてしまいました。
当面の間、ZFSコードベースが更新されることは期待できないでしょう。
/etc/rc.dを眺めていると、 /etc/zfs/zpool.cacheの存在を手掛かりにアクティベートされることがわかります。
なにもない最初の状態でZFSを触るときは、 ZFSを操作する前にsolarisモジュールとzfsモジュールをカーネルに組み込みます。 ライセンスの都合でZFS対応コードはすべてモジュールに分離されており、 静的に組み込まれることは将来もないでしょう。
# modload solaris # modload zfs
カーネルモジュールとしてロードされる都合上、 ZFSをroot filesystemとして使用することはできません。 触る場合はNetBSDの全体を伝統的なFFSとして起動ディスクにインストールし、 ZFS領域は別ディスクにデータ用として取ることをおすすめします。
NetBSD ZFSのバージョンは初期移植の段階以後はメンテナンスされておらず、 放置されている都合、古いままとなっています。
# zpool upgrade This system is currently running ZFS pool version 23. All pools are formatted using this version. # zfs upgrade This system is currently running ZFS filesystem version 4. All filesystems are formatted with the current version.
ZFSのチェックサムはFletcherと呼ばれるチェックサムです。 単なる足し算に細工をして名前を付けたものと理解してください。 SHA256のように凝ったことをしているわけではなく、 ある程度のビット化けを検出することができるにすぎません。 SHA256のような凝ったチェックサムを採用しなかったのは、 計算の簡便さと速度を採ったためでしょう。 ファイルシステムレベルでのチェックサム違反はそう滅多に発生するものではないからです。 ZFSの特徴はチェックサムに桁数を長く採っていることと、 常にチェックされるということです。
チェックサムを保存する領域はZFSのメタデータに確保されており、 チェックサムを禁止してもそれがユーザデータ領域として開放されることはありません。 基本的にチェックサムは常に有効でなければなりません。
ZFSは最小1セクタを単位として可変長ブロックを割り当てます。 このことはディスクに「効率的な割り当ての難しい隙間」を作る断片化を起こすことを意味します。 NASを運用する場合はディスク容量に余裕を持たせることが重要です。
ZFSはチェックサムを照合するために書き込んだブロック全体を読み出します。 128KBで書き込まれたブロックは必ず128KBまるごと読み込まれます。 このことはディスクI/O回数を節約する意味がある反面、 少量の読み出しでもキャッシュメモリを激しく消費することを意味します。 NASを組む場合は可能な限り大量のメモリを積み込むことが重要です。
いまどきのHDDは4K sectorですから、 ストレージプールを作成するときは4096バイト単位で割り当てるよう指定することを忘れないようにしましょう。
RAIDZ1はRAID5相当ですが、パリティの取り方が違います。
RAID5はデータもメタデータも区別はなく、 パリティはディスク1本分でした。 RAIDZ1においてはメタデータや小さなファイルは、 ディスク本数にかかわらずミラーリングになります。 昨今の4K sectorディスクにおいて1セクタは4096バイトですから、 4096バイト以下のメタデータと小さなファイルは、 ミラーリングとして2セクタを消費します。 塵も積もれば何とやらでディスク容量の50%をパリティとして消費するのです。 RAID5でみられたパリティの節約効果は、 RAIDZ1においては巨大なデータブロックのみとなります。
RAID5は一般的に2^n+1本のディスクで構成し、 すなわち3本・5本・9本のいずれかでないと性能が出ませんが、 RAIDZ1にはそのような縛りはありません。 空きブロックがどのように消費されるかはファイルサイズにも依存するからです。 4096バイト以下のファイルは2ディスク、 8192バイト以下のファイルは3ディスク、 12288バイト以下のファイルは4ディスクに跨って空きブロックを消費します。
メールサーバやソースコードのように、 ごくごく小さなファイルを多数集積する場合は伝統的なFFSのほうが有利です。 動画や音楽波形など巨大なファイルを集積する場合はZFSが有利です。 堅牢性を狙ってRAIDZでメールサーバを構築する場合は、 RAIDZのパリティがディスク容量の50%にも及ぶことを忘れないようにしましょう。
NetBSDにある日突然ZFSが持ち込まれましたが、 追ってストレージに採用する者が現れることはありませんでした。 年月を経て、そのまま無人の廃墟となりました。
2016年現在は、無人の荒野として遺構の存在のみを現代に伝えています。 カーネルコンパイルのエラーを修正する人が立ち入って、 コンパイルの障害となるコードを修正することがある程度です。