一块企业级SSD，倒在了65535小时

办公室 NAS 上的 Seafile 最近经常失去响应。

Docker 容器看起来还在运行，但网页打不开，连 docker compose down 都会卡住。彻底关机再开机，又能正常几天。

我一直怀疑这台机器的主板或者供电有问题。它用的是 B365 主板，以前同时插两块 M.2 SSD，很容易有一块掉线。后来只留一块，稳定了很多。

这次不是主板，而是一块用了七年半的 Micron 5200，撞上了固件里的 65535。

SSD 坏了？ #

Seafile 又一次挂掉后，我跟 Codex 说：你上去看看。

它 SSH 到服务器检查，发现容器还在，但本机 HTTP 请求已经超时。系统 load 接近 78，还有 78 个进程卡在 D 状态，全都在等 I/O。

Seafile 的数据放在一个 ZFS mirror 上，两块盘分别是 Micron 5200 PRO 1.92TB 和 Crucial MX500 2TB。Micron 的平均写延迟接近 250ms，MX500 只有 0.3ms。问题明显在 Micron。

但 SMART 又说它没坏：

Firmware:                   D1MU030
Power_On_Hours:             66292
Reallocated_Sector_Ct:          0
Reported_Uncorrect:              0
Command_Timeout:                85
Percent_Lifetime_Remain:        95%

这块盘是我三年前二手买的，企业级，高 TBW，已经写了约 378TB，温度只有 29°C。

SMART 的最终结论甚至是 PASSED。

所以不是 Seafile 自己挂了，是它在等一块迟迟不给响应的硬盘。

换 SATA 口 #

这台机器有 6 个原生 SATA 口和 2 个扩展口。为了排除主板问题，我把 Micron 从原生口挪到了扩展口。

换完正常了大约 47 小时，Seafile 又挂了，症状完全一样。

问题跟着硬盘跨了控制器，基本可以排除原来的 SATA 口。

我有每小时一次的 rsync 备份，也能接受最近一小时的数据丢失，就决定取消 ZFS 镜像，只留 MX500 单盘运行。

Codex 执行 zpool detach，结果命令也被硬盘卡住了。我问它能不能直接热拔，它说有风险，但镜像另一边和备份都正常。

最后是我把 Micron 直接拔了。

内核记录了一堆超时和 SATA reset，之前卡住的 detach 随后完成。ZFS 恢复 ONLINE，没有数据错误，Seafile 也立刻恢复了。

盘确定了，但它为什么会这样？

65535 #

我又问 Codex，SMART 真的看不出问题吗？

它翻了服务器里的 SMART 历史记录，找到两行：

2026-08-02 21:12:38  Power_On_Hours = 65535
2026-08-02 22:12:37  Power_On_Hours = 65536

65535 = 2^16 - 1 = 0xFFFF

程序员看到这个数字，基本都会警觉。65535 小时约等于 7.48 年，这块盘恰好在越过它以后开始频繁卡死。

Codex 随后搜到了这篇 Reddit 帖子：WARNING: MICRON 5200 fails after 65535 hours。里面很多人的情况都一样：超过 65535 小时后，速度可能跌到 1MB/s 以下；SMART 仍然正常；彻底断电后能暂时恢复。

一开始我们猜是某个 16 位计数器溢出了。后来找到的 Dell 官方说明证实了这个方向：固件用 16 位计数器记录 workload log，到 65535 后开始不停生成调试日志，SSD 控制器的 CPU 被占满，读写越来越慢；HPE 的固件说明也写着，新固件修复了这个问题。

跟 NAND 坏没坏、温度高不高都没关系，格式化也解决不了。

找固件 #

这块盘原来的固件是 D1MU030，要升级到 D1MU040。

但 Micron 当前的公开下载页已经找不到 5200。我先找到一个 5300 的 D3MU048，把链接发给 Codex。它确认型号不对，不能刷。

后来从社区分享的 Hetzner Rescue System 固件包里找到了 D1MU040。Codex 解开包，检查 firmware.properties，确认支持 5200 PRO 1920GB，又核对了 MD5 和 SHA256。

固件确认以后，我在办公室给 Seafile 买了新盘。旧盘不再放回生产环境，我把它带回家继续折腾。

USB 刷固件 #

我把盘接到本地 NAS，通过 USB Hub 转 USB-SATA，识别成了 /dev/sdc。

一般不建议隔着 USB-SATA 刷固件，桥接芯片不一定能完整透传命令，中途 reset 一次，盘就可能变砖。不过 Micron 的 msecli 能正确识别型号、序列号和 D1MU030。

我决定试一次。在网页 ChatGPT 的提示下，确认设备名以后执行：

msecli -F -U /root/1.bin -n /dev/sdc

然后一路看着那些点走完：

Firmware update operation completed successfully.
CMD_STATUS   : Success
STATUS_CODE  : 0

刷完以后，我让硬盘真正断电，再重新上电。smartctl 和 msecli 都显示固件已经变成 D1MU040。

写满一次 #

我不太相信“升级成功”四个字。原来的故障就是持续写入后才出现，所以我直接把整块盘写满一次：

dd if=/dev/zero of=/dev/sdc bs=16M status=progress oflag=direct

这个命令会清空整块盘，千万不要抄错设备名。

最终写满 1.92TB，用了大约 2 小时 40 分钟，平均 201MB/s：

1920383410176 字节已复制，9574.37 s，201 MB/s
dd: 写入 '/dev/sdc' 时出错: 设备上没有空间

最后这个报错是正常的，因为已经写到了裸盘的末尾。

写完后，Codex 又检查了一遍内核日志和 SMART：没有新增 timeout、USB reset 或 I/O error；坏块和不可校正错误仍然是 0；最高温度 53°C。

这块盘算是救回来了。我准备把它装到 Windows 电脑上当游戏盘，继续观察，不再承担重要数据。

最后 #

这次 Codex 干的基本是查证：远程看进程和负载、对比两块盘的延迟、翻 SMART 历史、搜厂商公告、核对固件包、写盘后复查日志。真正要拍板的——挪不挪口、拆不拆镜像、拔不拔盘、敢不敢隔 USB 刷固件、写不写满整块盘验证——都是我自己定的。

线索太散的长尾问题，AI 确实擅长串起来；但风险要不要冒，还是自己的事。

这块盘写了约 380TB，NAND 还有很多寿命。先撑不住的，居然是七八年前程序员留下的一个 16 位计数器。

后续 #

今天买的新硬盘到了，我告诉 Codex “新硬盘插入了，你看看，帮我加入 data 的镜像”

很快，Codex 找到了新硬盘，给 data pool 做了 z1 镜像，并告诉我resilver的进度。