บทบาท: คุณคือผู้รีวิวต่างค่าย (Gemini / Argon) ของโต๊ะรีวิว homelab media — รีวิว "แผน" นี้แบบไม่เกรงใจ (truth over politeness)
กติกา: วิเคราะห์เท่านั้น · คุณเปิดไฟล์ในเครื่องผมไม่ได้ ⇒ อย่าเขียนว่า "ตรวจโค้ดแล้ว" ให้ใช้ "ต้องตรวจ:" นำหน้าเสมอ

=== ระบบปัจจุบัน ===
- Unraid 3 tower; เครื่องป่วย = Tower-HD · NVMe pool ลูกเดียว 932 GB ไม่มี mirror = /mnt/cache_smb · share Movies ตั้ง cacheUse=yes ⇒ ทุกการเขียนใหม่ลง NVMe ก่อน
- NVMe hot-cache tier 3 ขา: promote (คัดลอกไฟล์ฮิตขึ้น NVMe + rename ตัวบนอาเรย์เป็น .plexcached) / retain (คัดลอกลงอาเรย์ + เก็บของบน cache) / drain-demote (ถอนของเย็นลงอาเรย์)
- drain = สคริปต์ nvme_drain ทำงานทุก 10 นาที: fill ≥70% ⇒ เลือกวิดีโอ "เก่าสุดก่อน" (ctime ≥2 ชม. · ไม่อยู่ใน pin list 83 ไฟล์ · ไม่ถูกเปิดอยู่) ตามงบ = rate × 600 วิ × 0.9 ⇒ ส่ง move_engine (dd O_DIRECT) ที่ถาม "เกียร์" รายไฟล์ (คนดู/await ของดิสก์)
- cache_guard: fill ≥85% ⇒ latch + สั่งหยุด qBit (หยุดโหลด) · ปลดเมื่อ ≤80%
- mover ของ Unraid (ขาระบายที่ 2) ไม่มีตารางเลย = ไม่รัน · มี skip list กันวิดีโอ (78 path + 5 wildcard)
- ของเข้า: pipeline พาร์ทเนอร์ (sftpgo-lookgata + mover-web บน Tower-8K) เขียนข้ามมา HD ผ่าน SMB · ไม่จำกัดอัตรา

=== ข้อเท็จจริงที่วัดเอง 2026-10-21 (เชื่อถือได้) ===
- แคชค้าง 83-85% ตั้งแต่ 06:29 → latch ทำงาน → qBit HD หยุด 5 ตัว (+20 stoppedDL) → ลูกค้าดาวน์โหลดใหม่ไม่ได้ ~5 ชม. · free 163 GB
- drain 6 ชม.: ย้ายออก 207 GiB / 135 ไฟล์ · effective 10.6 MB/s · ต่อไฟล์ 24.8 MB/s · ไฟล์เฉลี่ย 1.58 GiB
- duty cycle = 49% (งานจริง 2.78 ชม. จากหน้าต่าง 5.71 ชม.) · ช่องว่างระหว่างไฟล์ 600-1,020 วิ = รอ tick 10 นาที
- ingress 240 GiB / 5 ชม. (ซีรีส์จีน/ไทย ตอนละ 1-1.4 GB) ≈ อัตราระบาย ⇒ net 8 ชม.เกือบศูนย์
- ละเมิดหลัก: drain ถอนตาม "อายุ + pin list" เท่านั้น ⇒ 12 ชม.ถอน 325 ไฟล์ มี 4 ไฟล์ที่เพิ่งถูกดูใน 72 ชม. · ตอนนี้มี 9 ไฟล์ "ดูใน 72 ชม. + อยู่บนแคช + ไม่อยู่ใน pin" รอโดนถอน (หนักสุดถูกดู 826 นาที)
- tier scorer ตัดสิน demote=0 / expired=8 / ไฟล์บนแคช 763 (ขัดกับ drain ที่ถอนอยู่)
- lock ค้าง: nvme_cycle_hd.lock อายุ 9 ชม. ทำให้ drain log ว่า "มี cycle วิ่งอยู่ ⇒ ข้าม"

=== หลักที่ยึด (มี backtest ในบ้านแล้ว) ===
1. promote กล้าได้ / demote ต้องขี้ระแวง (fail-closed) — ถอนผิด = ลูกค้ากระตุกทันที
2. ห้ามใช้ "นาทีที่ดิสก์ตัน (hot_n)" ตัดสิน demote — ไฟล์บน NVMe ได้ hot_n=0 เสมอ (วงจรถอน-ยกซ้ำ) · ใช้เวลาเล่นจริง (ts / n / v) แทน
3. เกณฑ์ที่ backtest แล้ว: ปกป้องไฟล์ที่ถูกดูใน 72 ชม. หรืออ่าน ≥5 GB ใน 7 วัน → ลดอ่าน HDD 78-84%
4. retain/สำเนา = คัดลอกลงอาเรย์ + เก็บของบน cache (ไม่กินโควตาสลับ inode) · ตัดสินก่อน mover 06:30
5. invariant: ห้ามย้าย inode ที่มีคนถือ · ต้องมีสำเนาบนอาเรย์เสมอ · สมองเดียว ห้าม 2 process แย่งโควตา fileid · ต้องหยุดได้ทันที

=== แผนใหม่ v2 (สิ่งที่ต้องรีวิว) ===
ระยะ 1 (24 ชม.)
 P1 Interest Guard ใน drain (fail-closed): ก่อนถอน ตรวจ 72 ชม. / ≥5 GB ใน 7 วัน / ถูกเปิดอยู่ / อยู่ใน pin ⇒ ข้าม · ข้อมูลจาก diskio_seen.json (ต่อไฟล์: ts/n/mbps/v/gb) + ruleboard_events.jsonl · กัน starvation ของไฟล์เย็น ≥7 วัน · เกณฑ์สำเร็จ: ไฟล์ที่ถูกดูใน 72 ชม. ถูกถอน = 0
 P2 Duty 49% → ≥80%: fill ≥75% ระบายต่อเนื่องไม่รอ tick · งบอิงไบต์/วินาที ไม่ใช่ 600 วิตายตัว · fill ≥83% = โหมดวิกฤตจน <78% · ทางลัด: one-off --mode manual --rate 120 --gb 250 (ยังถามเกียร์รายไฟล์ + เคารพ pin) คาด 45-70 นาที 83%→~57%
 P3 Ingress brake + observability: fill ≥80% ลด/หยุดคิว push ของ mover-web ที่ Tower-8K (hold ที่ต้นทาง ไม่เสียข้อมูล) · state file เดียว cache_state.json (pool/band/latch+since/phase/worker/blocked_by ∈ gear_await|in_use|hot_guard|budget|lock|ingress + inventory cold_eligible_gb) · CLI cache-status --why
ระยะ 2 (1 สัปดาห์): continuous worker + token bucket · เลือกไฟล์แบบ bin (1.5-5 GiB ก่อน > 5 GiB > <1.5 GiB เก็บกลางคืน) เพื่อ amortize ต้นทุนสลับ ~80 วิ/ไฟล์ · leading indicators (ΔR = ingress−drain, Time-to-Latch, Cold Reservoir Ratio, Duty Deficit)
ระยะ 3 (2-4 สัปดาห์): ยุบ policy ของ drain+copyleg เข้า cache_guard (สมองเดียว) · move_engine = worker ไร้สมอง · ลบ lock อิสระ · retain/early-mirroring ให้ demote = unlink · (ไม่ทำ) เอา Unraid mover กลับมาแตะ Movies

=== ความเสี่ยงที่แผนระบุไว้ ===
- เขียนอาเรย์เร็วขึ้น → คนดูกระตุก ⇒ เกียร์รายไฟล์ยังอยู่ + one-off จำกัด rate + เฝ้า await
- Interest guard เข้มเกิน → ไม่มีของถอน → เต็ม ⇒ Cold Reservoir Ratio เตือน <15% + emergency band (ห้ามแตะไฟล์ที่เปิดอยู่)
- ingress brake = ข้ามเครื่อง/ข้าม container ⇒ อาจไม่ใช่จุดที่ควรบังคับ

=== สิ่งที่ขอให้ตอบ (ตอบเป็นข้อ 1-8) ===
1. วินิจฉัย: "duty 49% + ingress ~48 GB/ชม. + guard ไม่มี interest" ครบไหม มีสาเหตุอื่น/เชนผลกระทบที่แผนมองข้าม
2. แผน 24 ชม. (P1/P2/P3) กัน latch 85% ได้จริงหรือแค่ชะลอ · จุดใดจะล้มเหลวก่อน
3. Interest guard จาก diskio_seen.json (คีย์เป็น basename ต่อ disk) — จุดพังที่ต้องระวัง (rename / ย้ายดิสก์ / ชื่อซ้ำ) และ fallback ที่ควรมี
4. One-off 250 GB ที่ rate 120 — ความเสี่ยงจริงต่อคนดู 50-70 คน และต่อ parity/array · ควรจำกัดเงื่อนไขอะไรก่อนยิง
5. Ingress brake ที่ mover-web (อีกเครื่อง อีก container) ทำได้จริงไหม หรือควรแยกเป็นระบบต้นทาง · backpressure ต้นทาง vs ปลายทาง
6. Observability: state file + cache-status --why — schema ครบไหม ขาด field ไหนที่จะทำให้ debug ช้า · ยกตัวอย่างคำถามที่ยังตอบไม่ได้
7. Ownership map (cache_guard = latch/คุมรอบ · nvme_drain = เลือกไฟล์ · nvme_copyleg = ขา copy + lock · move_engine = ย้ายไบต์ · nvme_heat = pin 02:00 · sftpgo+mover-web = ingress · Unraid mover = หลับ) — จุดไหนยัง "สองคนเป็นเจ้าของเรื่องเดียว"
8. ถ้าเลือกทำเพียง 2 อย่างใน 24 ชม. เพื่อหยุด latch + ลดความเสี่ยงลูกค้า — เลือกอะไร และอะไรควร "หยุดทำ"

=== บังคับแนบท้าย: Scorecard D1-D10 ===
ให้คะแนน 1-5 ต่อมิติ พร้อมเหตุผล 1 บรรทัด + มาตรฐานสากลที่เทียบ (DORA / Google SRE / OWASP / AWS Well-Architected ฯลฯ) · ห้ามให้เท่ากันทุกมิติโดยไม่มีเหตุผล
D1 ความเร็วถึงมือลูกค้า · D2 คุณภาพ/กันของเสีย · D3 ความทนทาน/กู้ตัวเอง · D4 การสังเกตได้/ตัววัด · D5 ความง่ายในการดูแลโดย AI · D6 ความปลอดภัยของการเปลี่ยน · D7 ความเรียบง่ายสถาปัตยกรรม · D8 การใช้ทรัพยากร · D9 การกำกับดูแล/สิทธิ์ตัดสินใจ · D10 ประสบการณ์ลูกค้า/สื่อสาร
ปิดท้าย: คะแนนรวม /50 · 3 จุดที่ควรแก้ก่อน (เรียงตามคุ้มเสี่ยง) · 1 จุดที่ควร "หยุดทำ"

ตอบภาษาไทย กระชับ ตรงประเด็น ไม่ต้องเกริ่นนำ · ใช้หัวข้อเลขตามที่ขอ