ZFS Blog
図解と実機検証ベースのZFS技術記事シリーズ。
スナップショット整理スクリプトがレプリケーションを壊した話
友人宅へのオフサイトレプリケーションが、ある夜から突然フル転送に戻ってしまい、細い自宅アップロード回線で3日がかりになったことがあります。原因は、スナップショット整理スクリプトがincremental sendに必要な共通スナップショットを消してしまっていたことでした。フル/incremental sendの仕組み、bookmarkによる軽量な差分管理、resumable sendが実際にどう救ってくれるかを整理します。
レンダーキャッシュを消した直後だけタイムラインがカクつく
`homenas`で4K素材を編集していて、DaVinci Resolveのキャッシュを掃除した直後だけタイムラインのスクラブがカクつくことに気づきました。犯人はasync destroyのバックログと、キャッシュ/プロキシファイルの高頻度な作成・削除によるプールの空き容量断片化でした。動画編集ワークロード特有のデータセット分離、recordsize設計、async destroyとの競合を避けるチューニングを整理します。
新しいマシンで読み込んだプールが、古いマシンに二度と戻らなくなった話
`homenas`を新しいハードウェアに載せ替える途中、念のため旧機でも動作確認しようとしたら、二度とインポートできなくなっていました。原因はプールのversion番号ではなく、feature flagという一方通行の仕組みでした。legacy versionとfeature flagsの違い、なぜ一度アップグレードすると戻れないのか、そして詰んだときの読み取り専用インポートによる救出手順を整理します。
PostgreSQLのIOPSが計算通り出なかった理由がrecordsizeだった話
ワークロードのIOPS要件から逆算してディスク本数を決めたはずのPostgreSQLサーバーで、実際のIOPSが計算値の何分の1も出ていなかったことがあります。犯人はrecordsizeをデフォルトの128KiBのまま放置していたことでした。読み込み増幅の仕組み、なぜ後から変更しても既存データには効かないのか、そして圧縮アルゴリズムの選び方を図解つきで整理します。
スナップショット一括削除の直後にバックアップを繋げて原因調査に半日溶かした話
仕事の基盤チームで、古いスナップショットを一括削除する定期ジョブの直後にバックアップジョブを繋げていたら、原因不明の性能劣化に悩まされたことがあります。犯人は`zfs destroy`後もバックグラウンドで解放処理が続く非同期解放(async destroy)でした。仕組みと`freeing`の監視方法、クローン削除を高速化するlivelist、削除運用でハマりがちな落とし穴を整理します。
日曜夜のscrubで家族に不満を言われた話
何も考えずcronで週次scrubを日曜21時に設定していたら、家族の動画配信視聴とまともにぶつかって苦情が来たことがあります。scrubの頻度設計、resilver中の二重障害リスク、sequential resilverとの違い、そしてHDDプールでの所要時間見積もりを実務目線で整理します。
家族共有フォルダのACLをバックアップスクリプトで消した話
`homenas`のSamba共有で家族ごとにNFSv4 ACLを丁寧に設定していたのに、深夜のバックアップスクリプトが`chmod -R`を叩いて全部リセットしていたことがあります。ZFSのACLがなぜPOSIXのモードビットと二重管理になるのか、aclmode/aclinheritでどこまで制御できるのか、そしてこの問題を統一しようとして結局カーネルに入らなかったrichaclの構想を整理します。
special vdevで一度プールを飛ばした話
「余っているNVMeをspecial vdevにすればHDDプールが速くなる」— 自宅のhomenasで実際にこれをやって、単一障害でプール自体を失いかけたことがあります。special vdevはL2ARC/SLOGと違い、失えばプール全体を道連れにする本番のメタデータ格納先です。冗長性の鉄則、容量見積もり、そして「後から外せると思っていたら外せなかった」問題を、実際の失敗談ベースで書きます。
SLOGを足したのに何も速くならなかった話、と後で気づいた本当の危険
自宅の`homenas`でNFS共有を少し速くしたくて余っていたコンシューマ向けNVMeをSLOGにしたら、体感速度がまったく変わりませんでした。理由は単純で、そのとき動いていたのはほぼ非同期書き込みだったからです。もっと怖かったのは後から知ったPLP(電源損失保護)の話でした。ZILとSLOGの役割分担、SLOGが効く条件、そして「PLPなしSSDをSLOGにする」という最も危険な落とし穴を整理します。
dedupを切り忘れたVMストアが返ってこなくなった話
検証のつもりで`dedup=on`にしたVMストアをそのまま忘れて本番投入し、半年後に容量整理で`zfs destroy`を叩いたら丸一日プールが返ってこなくなったことがあります。DDT(dedupテーブル)がRAMから溢れた瞬間に何が起きるのか、事前にどう見積もればよいのか、そして多くの場合dedupより先に検討すべき代替手段を整理します。
ashiftを間違えたまま2年運用していた
初代`homenas`は512eディスクの自動判定ミスで`ashift=9`のまま組んでしまい、気づいたのは2年後でした。RAIDZ1/2/3の選択、vdev幅、ashift — この3つはプール作成の瞬間に固定され、後からディスク1本足すような気軽さでは直せません。resilverリスクとashiftの不可変性という実務上の制約から整理します。
オフサイトバックアップに平文を送っていた話
友人宅のNASへオフサイトバックアップを組んだとき、`zfs send`に`-w`を付け忘れていたことに数ヶ月気づきませんでした。暗号化データセットは既定の送信方法だと送信元でいったん復号されるため、平文がネットワーク越しに流れていたことになります。ZFSネイティブ暗号化の鍵管理と性能コスト、そしてこのraw sendの落とし穴を整理します。
L2ARCを足したら逆に遅くなった
`homenas`にRAM32GBのまま1TBのL2ARCを足したら、体感速度が足す前より悪化したことがあります。原因は、L2ARCの各エントリのヘッダ情報がARC(RAM)側に間借りしているという構造でした。ARCとL2ARCの関係、この見落としがちな制約、実務での判断フローを整理します。
容量は足りているのに遅い、というやつ
以前、新しいVM基盤の容量見積もりだけ済ませて本番投入し、稼働後に「遅い」と言われて青ざめたことがあります。原因は単純で、IOPS要件を誰も聞いていませんでした。この記事では、ワークロードのIOPS要件からZFSのvdevトポロジーを逆算する実務プロセスを、具体的な数値と自宅VMでの検証ログとともに解説します。
深夜にディスクが1本死んだときの手順
初めて本番でディスク故障のアラートを受けたのは深夜2時でした。幸いミラー構成で、パニックになる必要はなかったのですが、当時の自分は`zpool status`の読み方に自信が持てず、無駄に時間を溶かしました。zpool offlineからzpool replaceによる復旧、resilver完了確認までを実機のコマンド出力で追います。