---
title: "一块企业级SSD，倒在了65535小时"
url: "https://lerry.me/post/2026/09/micron-5200-65535-hours"
date: 2026-09-03T13:01:00.000Z
updated: 2026-09-04T03:27:20.979Z
tags:
  - "Linux"
  - "ZFS"
  - "SSD"
  - "NAS"
language: zh-CN
---

# 一块企业级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 又说它没坏：

```text
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 历史记录，找到两行：

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

```text
65535 = 2^16 - 1 = 0xFFFF
```

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

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

一开始我们猜是某个 16 位计数器溢出了。后来找到的 [Dell 官方说明](https://www.dell.com/support/kbdoc/en-us/000464492/poweredge-micron-5xxx-series-solid-state-drive-performance-degradation-after-65-535-poh?lang=en)证实了这个方向：固件用 16 位计数器记录 workload log，到 65535 后开始不停生成调试日志，SSD 控制器的 CPU 被占满，读写越来越慢；[HPE 的固件说明](https://support.hpe.com/connect/s/softwaredetails?collectionId=MTX-8c0c47d5bf1446e8\&language=en_US)也写着，新固件修复了这个问题。

跟 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 的提示下，确认设备名以后执行：

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

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

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

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

***

## 写满一次

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

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

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

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

```text
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的进度。