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

=== ระบบปัจจุบัน (โครงเดิม) ===
- 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 มี wildcard `*.mkv|*.mp4|*.ts|*.m2ts|*.avi` ⇒ กันวิดีโอ Movies ทั้งหมด (mover ช่วย Movies ไม่ได้เลย)
- ของเข้า: pipeline พาร์ทเนอร์ (sftpgo-lookgata + mover-web บน Tower-8K) เขียนข้ามมา HD ผ่าน SMB · ไม่จำกัดอัตรา

=== ข้อเท็จจริงที่วัดเองวันนี้ 2026-10-21 (เชื่อถือได้ · ตัวเลขจาก log/df/API จริง) ===
[A] อัตราที่แท้จริง
- drain ปกติ (ผ่านด่านเกียร์): effective 10.6 MB/s · ต่อไฟล์ 24.8 MB/s · duty cycle 49% · ช่องว่างระหว่างไฟล์ 600-1,020 วิ (= รอ tick 10 นาที)
- ingress ที่วัด 3 ชม.: 551 ไฟล์ / 66.2 GiB = 23.7 GB/h · เคยเห็น burst 122 MB/s ตอน qBit กลับมาทำงาน
- เพดานอาเรย์จริง (parity write): 22.6 MB/s ≈ 81 GB/h ⇒ drain เต็มสปีดก็ ≈ 3.4 เท่าของที่ทำได้ตอนนี้
- one-off manual 249 GB / 171 ไฟล์ @rate 120 (ยังไม่ bypass) ⇒ 83%→81% ใช้ ~2 ชม.
[B] เหตุการณ์ flap (ใหม่ · สำคัญที่สุด)
- 13:05 ปลด latch ที่ free 200 GB (fill ~78%) → qBit กลับมาโหลด → ingress พุ่ง 122 MB/s → fill กลับไป 96% / free 40 GB ภายใน ~30 นาที → latch ซ้ำ
- ⇒ ปัญหาไม่ใช่แค่ "ระบายช้า" แต่คือ "ปลด latch แล้วของเข้าเร็วกว่าที่ระบายได้ 5-10 เท่า" (122 vs 20 MB/s)
[C] bypass gear (สร้าง + verify + ใช้จริงแล้ววันนี้)
- env GEAR_BYPASS=1 ให้ move_engine ข้ามด่านเกียร์ เท่านั้น — brake / STOP / in_use / fileid pairing ยังทำงานครบ (ยืนยันด้วยเทส 138/0 · 131/131 · 48/0)
- วัดของจริง: net ~19-20 MB/s (1,387 MiB ใน 75 วิ) · 96% → 88% ใน ~50 นาที · มี in_use_avoid ทำงานจริง (ข้ามไฟล์ที่คนเปิด)
- ค่าเริ่มปิด (night_full.enabled=false) · วันนี้เปิดเฉพาะหน้าต่าง one-off 13:00-21:00 เพื่อระบายฉุกเฉินจน free ≥600 GB
[D] ลูกค้ากระตุกไหม (Boss ตั้งสมมติฐานว่าไฟล์ 1080p เล็ก ⇒ อาจไม่กระตุก) — probe 60 วิ/sample
- ระหว่าง bypass: playcheck case ที่ติด stall = 0 · await p95 เฉลี่ย 24.3 ms (max 29.8) · util max 44.5% · คนดูพร้อมกัน ~42
- stall จาก diskio_watch: ~12 ครั้ง/ชม. ทั้งตอนเกียร์ต่ำและตอน bypass (11:00=12, 12:00=11, 13:00=12) ⇒ ยังไม่เห็นว่ากระตุกเพิ่ม
- ข้อจำกัด: 18-25 นาที ยังไม่พอสรุป (ต้อง ≥1-2 ชม. + เทียบกับช่วงไม่มี drain เลย)
[E] ระบบเตือน/KPI ที่เพิ่งขึ้นวันนี้ (ของจริง ไม่ใช่แผน)
- เตือนภายในตามระดับ 88% / 93% / 96% + latch เข้า/ออก + ETA "อีก ~X ชม. ถึง latch" · ยิงจริง 1 ใบ 13:13:07 ที่ 95% (ไม่สแปม: 95→94→92% ไม่ส่งซ้ำ) · เทส 136/0
- KPI org: cache_fill_<tower> / cache_latch_h_<tower> / cache_alerts_<tower> ขึ้นการ์ดแผนกสตอเรจแล้ว (9 items)
- ก่อนหน้านี้: 96% แล้ว ไม่มีใครเตือน — รู้จาก Netdata ภายนอกอย่างเดียว (Boss สั่งว่า "อย่าให้รู้จากคนนอก")
[F] หนี้ที่ยังค้าง (ไม่เกี่ยวกับ cache แต่เจอระหว่างทาง)
- Appdata Backup ล้มต่อเนื่อง: ratings.db-wal / ratings.db-shm ถูกลบระหว่าง tar (ตั้ง dontStop=yes) ⇒ รอบถูก mark failed · retention ค้าง 229 GB / 5 โฟลเดอร์ -failed · ไฟล์ backup เก่าสุดที่ใช้ได้ = 30 วันก่อน
- ยังไม่มี cron mover (ค่าเดิมที่หาเจอ 02:30/09:00 ขัดกันเอง ต้องยืนยันกับ Boss)
- LOW_GEAR_MB=10 ใน move_engine = เพดาน fallback ตอนดิสก์ตึง (เป็นสาเหตุที่ drain ตกไป 10 MB/s)

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

=== แผน v3 (สิ่งที่ต้องรีวิว) ===
P0 — One-off ระบายฉุกเฉิน (กำลังรันอยู่ตอนเขียน): bypass + เป้า free ≥600 GB · เฝ้าด้วย probe 60 วิ (playcheck stall, await p95, viewers) · เกณฑ์หยุดฉุกเฉิน: playcheck stall เพิ่ม > 3 เคส/10 นาที หรือ await p95 > 40 ms ติดกัน 2 sample ⇒ หยุด bypass ทันที
P1 — นโยบาย bypass (ยังไม่ตั้งถาวร รอรีวิวนี้): ใช้เฉพาะหน้าต่างกลางคืน + มี min_start_pct / min_stop_pct (เช่น เริ่ม ≥78% หยุด ≤55-60%) + เพดาน GB/คืน · ห้ามใช้ตอนกลางวันมีคนดูเยอะ เว้นแต่เข้าเขตฉุกเฉิน
P2 — Interest Guard (fail-closed) ใน drain: ก่อนถอน ตรวจ 72 ชม. / ≥5 GB ใน 7 วัน / ถูกเปิดอยู่ / อยู่ใน pin ⇒ ข้าม · ข้อมูลจาก diskio_seen.json + ruleboard_events.jsonl · กัน starvation ของไฟล์เย็น ≥7 วัน · เกณฑ์สำเร็จ: ไฟล์ที่ถูกดูใน 72 ชม. ถูกถอน = 0
P3 — กัน flap (ใหม่ จาก [B]): (ก) ปลด latch ต้องมี headroom ไม่ใช่แค่ถึง 80% · (ข) ปลด qBit เป็นขั้นบันได (ramp) ไม่ปล่อยพร้อมกัน 25 ตัว · (ค) ingress brake ที่ต้นทาง (mover-web Tower-8K) เมื่อ fill ≥80% · (ง) ถ้า flap ≥2 ครั้ง/วัน ⇒ ลด release threshold ลงหรือเพิ่ม dead-band
P4 — Observability: state file เดียว cache_state.json (fill/band/latch+since/phase/worker/blocked_by ∈ gear_await|in_use|hot_guard|budget|lock|ingress) + cache-status --why + leading indicators (ΔR = ingress − drain, Time-to-Latch, Cold Reservoir Ratio, flap count/วัน) — เตือน/KPI มีแล้วใน [E]
P5 — เก็บกวาด: คืน cron mover สำหรับ non-Movies · แก้ Appdata Backup (WAL race) · ทบทวน LOW_GEAR_MB=10
(ไม่ทำ) ลาก Unraid mover มาแตะ Movies

=== ความเสี่ยงที่แผนระบุไว้ ===
- เขียนอาเรย์เร็วขึ้น → คนดูกระตุก ⇒ ยังมี brake/in_use/STOP + probe เฝ้า + เกณฑ์หยุดฉุกเฉิน P0
- Interest guard เข้มเกิน → ไม่มีของถอน → เต็ม ⇒ Cold Reservoir Ratio <15% เตือน + emergency band (ห้ามแตะไฟล์ที่เปิดอยู่)
- ปลด latch เร็วเกิน → flap ซ้ำ (เกิดจริงแล้ว 1 ครั้งวันนี้) ⇒ P3
- ingress brake อยู่ข้ามเครื่อง/ข้าม container ⇒ อาจไม่ใช่จุดบังคับที่ถูก

=== สิ่งที่ขอให้ตอบ (ตอบเป็นข้อ 1-8) ===
1. วินิจฉัย [B] flap: 122 MB/s burst vs 20 MB/s drain — ต้องมี headroom เท่าไรจึงจะ "ปลด latch ได้อย่างปลอดภัย" · คำนวณจากตัวเลขข้างบนให้ดู (932 GB pool · latch 85/80) · วิธีคิดของผม (dead-band + ramp) ถูกทิศไหม หรือควรเปลี่ยนวิธีคิดเป็น "โควตาปลดครั้งละกี่ GB"
2. Bypass: ชุดด่านขั้นต่ำที่ต้องมีก่อนอนุญาตให้ bypass กลางคืนมีอะไรบ้าง · ควรมี await-based circuit breaker (เช่น p95 > 40 ms ติด 2 นาที ⇒ ถอยไปเกียร์ปกติ) ไหม หรือเป็นความคิดที่ทำให้ระบบสั่น
3. พารามิเตอร์กลางคืน: min_start_pct / min_stop_pct / เพดาน GB/คืน / ช่วงเวลา — ให้ตัวเลขที่ควรใช้ พร้อมเหตุผลจากอัตรา 20-22 MB/s · คุ้มไหมที่จะรัน 3-4 คืนติดเพื่อลงมา 40-50%
4. Interest Guard: จุดพังของ diskio_seen.json (คีย์เป็น basename ต่อ disk: rename / ย้ายดิสก์ / ชื่อซ้ำ) · fallback ที่ควรมี · และเกณฑ์ "ถูกดูใน 72 ชม." ควรนับจากอะไร (ts แรก / ts ล่าสุด / ผลรวมนาที)
5. "ลูกค้ากระตุกไหม": ตัววัดไหนที่ควรใช้ตัดสิน (playcheck stall/ชม. · await p95 · rebuffer ต่อ viewer-hour · %session ที่ stall) · ที่วัดได้วันนี้ (stall 0 · await p95 24.3 ms · 12 stall/ชม. เท่าเดิม) พอจะสรุปได้ไหม หรือต้องเก็บนานแค่ไหน · บนอาเรย์มี parity การรอ 24 ms ถือว่าปกติหรือสูง
6. Ingress brake: ควรบังคับที่ต้นทาง (mover-web/sftpgo ที่ Tower-8K) หรือปลายทาง (SMB throttle/qdisc ที่ HD) หรือที่ qBit (แยกกรณี qBit vs พาร์ทเนอร์) — เลือกทางเดียวและบอกว่าทำไม
7. นโยบายเตือน: 88/93/96 + ETA-to-latch + latch in/out พอไหม · ควรมีเตือน "flap count" และ "ΔR ติดลบต่อเนื่อง" ไหม · และเกณฑ์ไหนควรเป็น P1 ที่ปลุกมือถือกลางคืน (คนละระดับกับตอนกลางวัน)
8. ถ้าเลือกทำได้เพียง 2 อย่างใน 24 ชม. ต่อไป (หลัง one-off จบ) — เลือกอะไร เรียงตามคุ้มเสี่ยง · และ 1 อย่างที่ควร "หยุดทำ" ทันที

=== บังคับแนบท้าย: 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 จุดที่ควร "หยุดทำ"

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