RAIDZ設計の記事で「vdev幅はプール作成後に変えられない」と書きました。あれは今でも大筋では正しいのですが、OpenZFSにRAIDZ拡張(raidz expansion)という機能が入り、既存のRAIDZ vdevにディスクを1本ずつ追加できるようになっています。homenasで実際に使ってみて分かった、便利さと「思ったほど得しない」落とし穴を整理します。
投稿者: 宮田 | カテゴリー: 設計 | 難易度: 上級
友人宅へのオフサイトレプリケーションが、ある夜から突然フル転送に戻ってしまい、細い自宅アップロード回線で3日がかりになったことがあります。原因は、スナップショット整理スクリプトがincremental sendに必要な共通スナップショットを消してしまっていたことでした。フル/incremental sendの仕組み、bookmarkによる軽量な差分管理、resumable sendが実際にどう救ってくれるかを整理します。
投稿者: 宮田 | カテゴリー: 設計 | 難易度: 上級
homenasのSamba共有で家族ごとにNFSv4 ACLを丁寧に設定していたのに、深夜のバックアップスクリプトがchmod -Rを叩いて全部リセットしていたことがあります。ZFSのACLがなぜPOSIXのモードビットと二重管理になるのか、aclmode/aclinheritでどこまで制御できるのか、そしてこの問題を統一しようとして結局カーネルに入らなかったrichaclの構想を整理します。
投稿者: 宮田 | カテゴリー: 設計 | 難易度: 上級
「余っているNVMeをspecial vdevにすればHDDプールが速くなる」— 自宅のhomenasで実際にこれをやって、単一障害でプール自体を失いかけたことがあります。special vdevはL2ARC/SLOGと違い、失えばプール全体を道連れにする本番のメタデータ格納先です。冗長性の鉄則、容量見積もり、そして「後から外せると思っていたら外せなかった」問題を、実際の失敗談ベースで書きます。
投稿者: 宮田 | カテゴリー: 設計 | 難易度: 上級
検証のつもりでdedup=onにしたVMストアをそのまま忘れて本番投入し、半年後に容量整理でzfs destroyを叩いたら丸一日プールが返ってこなくなったことがあります。DDT(dedupテーブル)がRAMから溢れた瞬間に何が起きるのか、事前にどう見積もればよいのか、そして多くの場合dedupより先に検討すべき代替手段を整理します。
投稿者: 宮田 | カテゴリー: 設計 | 難易度: 上級
初代homenasは512eディスクの自動判定ミスでashift=9のまま組んでしまい、気づいたのは2年後でした。RAIDZ1/2/3の選択、vdev幅、ashift — この3つはプール作成の瞬間に固定され、後からディスク1本足すような気軽さでは直せません。resilverリスクとashiftの不可変性という実務上の制約から整理します。
投稿者: 宮田 | カテゴリー: 設計 | 難易度: 中級
友人宅のNASへオフサイトバックアップを組んだとき、zfs sendに-wを付け忘れていたことに数ヶ月気づきませんでした。暗号化データセットは既定の送信方法だと送信元でいったん復号されるため、平文がネットワーク越しに流れていたことになります。ZFSネイティブ暗号化の鍵管理と性能コスト、そしてこのraw sendの落とし穴を整理します。
投稿者: 宮田 | カテゴリー: 設計 | 難易度: 上級