hoelee
01c55805fb
Deploy / build (push) Successful in 27s
Second pass on articles already approved in Batch-02. Real fixes landed in 19de315; this commit records the outcome, the items that were already fixed before the reviewer's snapshot, and four reviewer misjudgements (the $TOKEN '***' artefact comes from the batch-packaging scrubber, not the posts; 06's User Scripts explanation was already correct; 11's Round 3 was already closed; the 'missing CTA' claims are false). One open question: 01's physical hardware anchor is unverified and was deliberately not invented. Tracker also carries the concurrently approved posts from the sibling session.
7.4 KiB
7.4 KiB
blog.hoelee.com 顾问二次审阅落地报告 — 同一批 11 篇 DevOps（顾问侧编号 Batch-05 / 内部 Batch-02）
对应资料包：顾问本轮报告的 11 篇 slug，全部为
audit-tracker.json中本已approved的 Batch-02 文章 性质：二次审阅（re-review）。顾问手上的文本快照早于上一轮修复，因此本轮报告中有相当比例的意见属于「已修好」的重复项。本文只记录真实增量修复与顾问误判澄清。 审批状态：11 篇维持approved，notes已更新为二次审阅记录。
一、结论摘要
| 分类 | 数量 | 说明 |
|---|---|---|
| 真实技术硬伤，本轮已修 | 6 项 | 集中在 11、04/09、06、03、02、01 |
| 上一轮已修好，顾问看到的是旧快照 | 9 项 | 标题 折腾、homelabs、rig/home server、英文有序列表坍塌、四周→三周、ZH 内链 /zh/、文末 CTA、代码 <details> 折叠、09 的 updatedDate |
| 顾问误判（站上正文无此问题） | 4 项 | Bearer ***、06 的 User Scripts 解释「说反了」、11 的第三轮悬念「未闭环」、多篇「缺文末 CTA」 |
| 需要作者本人给数字（未代填） | 1 项 | 01 的物理机型锚点 |
二、真实增量修复（本轮 commit 19de315）
1. why-telegram-bot-notifications-die（最重的一处）
- 源码级缺陷：
b"\r\n".join(body_lines)里的\r转义在历史流水线中被吃掉，导致行内代码跨行断裂、parts[]示例里的\r\n\r\n全部退化成\r\n\n。已用正确的转义重建该章节与示例代码。 - 原理解释改写：原文暗示
bytes.join()会改写元素内部的\r\n（错误）。现在明确两点真实机制：① 二进制流若先经过.splitlines()之类的按行处理，JPEG 内部的0x0D/0x0A会被改写为\r\n，同时与Content-Length失配；② 片段自带末尾\r\n时再 join 会得到--boundary\r\n\r\nContent-Disposition，在 MIME 里等于头部提前结束，nginx/1.30.1在 Bot API 之前就以 400 拒绝。 - 第三轮悬念：原文其实已有闭环段落，本轮把它写得更准（
PID 1跑内存中旧拼接路径、docker exec用刚改的脚本 + 最小 payload）。 - 人设：文末「internal production tool」表述上一轮已改好；本轮补物理锚点（Synology NAS / Portainer / Docker bridge /
PID 1）。 - Takeaway #4 同步改写，与新的机制解释一致。
2. the-cause-was-trim-not-the-ssds / when-smart-says-healthy-but-your-raid-is-corrupting-data
0x8941f998字段位置：确实是硬伤。盘读回全零块时，该值出现在found一侧（= 内核按盘上实际返回字节算出的值），wanted是 csum tree 里的期望值。两篇的日志行均改为wanted <expected> found 0x8941f998，并补上「看它落在哪一侧」的解释。- 字节序说明（本轮新增的实测结论）：4 KiB 全零块的规范 CRC32C 是
0x98f94189，内核按磁盘小端序打印出来才是0x8941f998。两篇都补了这一句，避免被资深读者当成「算错了」。 - 04 的时间线：
2026-09-22复核已过期，改为已发生的事实叙述（corrected_errors: 0、无新增csum failed、corruption_errs停在 sdd1=27 / sdb1=31）。 - 09 的闭环：
## The result/## 结果补上「转接卡也洗清了 → 根因是异步 TRIM」的最终更新与续篇链接；description同步为已定论版本（原文写着「仍未定论」）。
3. unraid-stop-array-hangs-on-swapfile
losetup -p 100：确认是错的，-p是--pass-fd（loop 加密遗留参数），与优先级无关。/boot/config/go示例与「脚本 2」均改为losetup "$LOOP" ...+swapon -p 1 "$LOOP"。/proc/swaps显示-2：这是「创建时未指定优先级」的内核默认值，与脚本里的swapon -p 1冲突。已补一段说明，说明那段输出来自加-p之前的那次运行，不伪造单一时间线的证据。
4. that-dying-ssd-was-just-a-bad-sata-cable
UDMA_CRC机制：改为「属性 199 只统计到帧时接口校验和出错（ICRC）；劣质线材通常走的是WRITE FPDMA QUEUED命令超时 + 链路重置，这类 I/O 在算出帧级 CRC 之前就被丢弃，所以计数器可以全程为 0」。- 破坏性写入警示：
fio --filename=/dev/sdd --rw=write代码块加了裸盘覆写警告（中英双语）。
5. synology-spreadsheet-api-is-a-container
- DSM 的
cpus:失效原因：由「内核没有 CPU CFS 调度器」改为「内核未编译开启CONFIG_CFS_BANDWIDTH（cgroup CPU 带宽控制），默认 CFS 调度器照常运行、只是没有配额可执行」。 - ZH CTA 的「小企业」→「中小企业（SME）」。
6. space-reclamation-wasnt-stuck-it-was-waiting
-344 GiB over 8 days=1.79 GiB/h，正文与趋势块由-1.5 GiB/h统一为-1.8 GiB/h。description里残留的「分两步 / in two steps」改为「分三笔 / three separate reclaims」，与表格 3 条回收项对齐。- frontmatter 补
blueprint: self-hosted-infrastructure+blueprintLayer: L1-compute-storage-network。
7. frontmatter / 小项
uploading-large-videos-to-youtube-via-cdp：补blueprint: ai-agent-automation+L1-deterministic-orchestration；CONTAINER_ID注释说明可直接填容器名（容器重建后短 ID 会变）。the-upstream-was-deleted-then-came-back-rewritten：补blueprint: sme-digital-suite+L4-managed-ops-handover；首段「给我家人 / for my family」改为「付费订阅读者与内部用户」。why-chrome-forgets-its-tabs-in-a-container：saved列表补空行过滤；补「空快照覆盖」边界条件与该护栏（/json/version的webSocketDebuggerUrl变化时才允许重开/覆盖）；补 blueprint 字段。
三、顾问误判澄清（站上正文无此问题，勿再改）
Bearer ***不存在：中英四篇的curl一直是$TOKEN。顾问看到的是批次打包文件的脱敏产物——生成批次时把$TOKEN当密钥抹成了***。这也是「中文版被误脱敏」这条意见反复出现的原因。- 06 的 User Scripts 解释没有说反：正文本来就写着「
At First Array Start Only只在开机后第一次触发、会跳过 GUI 停止→启动循环」，与顾问的纠正完全一致；真正错的只有losetup -p 100。 - 11 的第三轮悬念上一轮已闭环，不是断头线索。
- 「缺文末 CTA」不成立：01、03、04、09 等篇文末均有
[email protected]+ WhatsApp+60 12-797 2969双轨联系栏。
四、需要作者本人确认的一项
- 01 的物理硬件锚点：全文只写
volume1 42 TB/ DSM 日志，没有机型号。仓库内其它文章（02、mem0 篇）写的是Synology DS1821+，但本文未出现机型，没有代为填写——避免把两台不同设备合并。若确认是同一台，建议在首段补Synology DS1821+ (DSM 7.x)一句。
五、验证
npm run build通过（Pagefind 索引 319 页 / 35,341 词，零错误）。- 11 篇 × 双语 22 个文件跑过禁用词扫描（
homelab/home server/rig/家用/折腾/玩具/personal project/给我家人/小企业）与双向内链前缀检查（ZH 必须/posts/zh/，EN 不得含/zh/），0 命中。 - 代码围栏配对检查通过，无跨行断裂的行内代码。