[5ym]

なぜ

Z440 への移し替え(danything/gitops#642)で、PV の置き場が OpenEBS LVM の thin プール(約 340Gi)になる。thin なので PVC の合計はプールを超えて作れるが、今の raw 300Gi・encoded 1Ti のままだと:

• denpa の残量の見張り(src/lib/server/disk.ts)は PVC の中の空きしか見ないので鳴らない
• その前にプールが埋まり、denpa だけでなく全部の PVC の書き込みが止まる

何を変えたか

deploy/application.yaml の persistence で raw 64Gi・encoded 96Gi にした(chart の既定値は変えない)。

• ほかの PVC の合計は約 170Gi(AdGuard 31・Forgejo 54・Matrix 20・Rybbit 22 など)。プールの残りぎりぎりを denpa に回した
• raw は 5 チューナーで同時に 1 時間録ると 40GB ほどになるので多めにした
• 今の使用量は raw 10GB・encoded 3.4GB(DL360 の local-path を talosctl usage で測った)

注意

DL360 の local-path の PVC は縮められないので、Z440 で入れ直すまで denpa-chart の同期は PVC のところでエラーになる(AdGuard の PVC と同じ)。ほかのリソース(Deployment など)はそのまま当たる。入れ直しで新しい大きさの PVC が作られる。

🤖 Generated with Claude Code

https://claude.ai/code/session_01T9PbUfqG4pPxus99UeLiJs

[claude]

Claude finished @5ym's task in 23s —— View job

---

レビュー結果

deploy/application.yaml に persistence.raw.size と persistence.encoded.size を足しただけの変更で、YAML の構造は正しく、キーも chart の values.yaml (persistence.raw.size, persistence.encoded.size) と合っています。ブロッカーになる不具合やセキュリティ上の問題は見つかりませんでした。chart の既定値は変えず、この家の値だけを deploy/ に置く方針とも一貫しています。コメントで理由と前提が説明されているのも良いです。

要確認(任意)

1. 余裕がかなり薄い。 denpa の PVC 合計は raw 64 + encoded 96 + data 5 + agentConfig 0.125 ≒ 165Gi です。ほかの PVC が約 170Gi なので、合計は約 335Gi で、プール約 340Gi との差は約 5Gi です。thin プールではスナップショットやメタデータ分も食うので、ほかの PVC が少し育つだけで超えます。コメントの「ほかの PVC を増やしたら、ここを減らす」が運用上の唯一の歯止めです。意図した割り切りなら問題ありませんが、encoded をもう少し小さくする余地があるか見ておくとよいです。encoded の今の使用量は 3.4GB です。
2. 残量の見張りの閾値と raw の大きさ。 DISK_LOW_THRESHOLD の既定は 20GiB (src/lib/server/config.ts:256) です。raw が 64Gi だと、使用量が約 44Gi に達した時点で警告が出ます。5 チューナー同時 1 時間(約 40GB)では、録画の終わり際になってやっと鳴るか、鳴らずに終わります。閾値を変えるか、raw をもう少し取るかは判断が要ります。
3. PR 本文の「同期は PVC のところでエラーになる」について。 local-path の PVC は縮められないため、Z440 に入れ直すまで denpa-chart は OutOfSync/Degraded のままです。protectFromPruning: false なので、入れ直しのときの PVC 削除と再作成は git の変更どおりに進みます。本文に書かれている想定どおりです。ただし、その間 selfHeal や自動同期のリトライが他のリソースの反映を止めないかは、gitops 側で確認してください。

テストは設定値の変更のみなので不要です。