CPUが貧弱だと速度が出ません。 その一方、CPUが強力すぎるとバグが叩き出せないかもしれません。
ZFSは自動ではカーネルに組み込まれません。 /etc/rc.conf に zfs=YES を記述して /etc/rc に任せて明示的に組み込みます。
ZFSはあの厄介すぎるライセンスの都合から、 カーネルに直接リンクして単一バイナリにコンパイルされません。 カーネルモジュールを読み込むことが肝なので、 システムアップデート時にカーネルだけでなくカーネルモジュールも一括して更新する必要があります。 アップデート手順に考慮漏れがある場合は、お手元の手順書に加筆しておくことをお勧めします。
raidzは伝統的なRAID5に匹敵する構成ですが、 データ量に応じてミラーに縮退する性質を持ちます。 ディスク本数が3本や5本に限定されたりはしません。 raidzであれば、ディスク4本の構成でも使い物になります。 ホットスペアは検討していませんのでコメントできかねますが、 データセンターなどの隔離された場所に設置する物理システムの場合は ホットスペアもしくはraidz2を検討する価値があります。
プール名はそのままマウントポイントとして利用するべく命名する方法と、 ボリュームマネージャとしての利用に割り切って別名を与える方法があります。 一般的な利用方法は zpool 等と命名して、 データセットにマウントポイントを別途指定することです。
データセットの作成は必須ではなく、 プール名をそのままトップディレクトリとみなして利用することもできます。
どのようなスタイルで管理したいのか考えて名前を決めます。 ファイル名となる名前空間をざっくり設計しましょう。
命名準備が整ったらZFS physical vdevとなるボリュームを用意します。 パーティションで提供する場合は、 親ボリュームのパーティションスキームはGPTとします。
パーティションで与える場合、
最近(?)の -current であれば gpt(8) が -t zfs として認識します。
もしなければ FreeBSD ZFS (fbsd-zfs) を指定します。
物理ボリュームを与える場合、その物理ボリュームにパーティションテーブルは必要ありません。
GPT に fbsd-zfs を指定しても unknown type としてカーネルに認識されますが無視してOKです。
(partition type の情報は使われていない?)
SSDを利用してSLOGを与える場合は、 ZFSに組み込みたいボリュームのサイズが小さいことから GPTを用いて部分を切り出してストレージプールに与えることになると思います。
4KB物理セクタを採用するAFT HDDを組み込む場合はashift=12のオプション指定を忘れずに。
# zpool create export raidz wd2 wd3 wd4 wd5
# zpool add export log dk1
# zpool status
pool: export
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
export ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
wd2 ONLINE 0 0 0
wd3 ONLINE 0 0 0
wd4 ONLINE 0 0 0
wd5 ONLINE 0 0 0
logs
dk1 ONLINE 0 0 0
errors: No known data errors
データセットの作成は任意です。
必ずしも必要ではありません。
スナップショットを作りたい場合も、
スナップショットを作成したいグループとなる単位でデータセットを作成したほうが良いでしょう。
# zfs create export/home
# zfs create export/netbsd
# zfs create export/samba
下記は適当にファイルを書き込んだ後の様子:
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
export 138G 2.49T 129G /export
export/home 31.4K 2.49T 31.4K /export/home
export/netbsd 8.93G 2.49T 8.93G /export/netbsd
export/samba 31.4K 2.49T 31.4K /export/samba
プール直下にファイルを置くのではなく、 マウントポイントを別途指定したい場合はデータセットを作る必要があります。
定期的にzpool scrubを実行します。
NetBSD 9.0_STABLE