上个月我写过NAS电费那篇的时候提过一嘴：开了硬盘休眠之后，我在后台看到一晚上被唤醒40多次。当时只是果断把下载器的配置挪去了固态，没展开讲。后来评论区好几个人问我同样的问题——明明设了10分钟休眠，硬盘怎么整夜都在转，摸上去温温的，一点睡的意思都没有。这篇就把我那晚的排查过程完整写出来，偷写盘的家伙就那么几个，挨个对号入座。
先确认硬盘到底睡没睡，别只看指示灯
排查的第一步不是乱设一通，而是先拿到证据。我有三个土办法，一个比一个硬：
| 方法 | 怎么操作 | 靠谱程度 |
| 听和摸 | 夜里贴着机箱听马达声，手摸盘位外壳感知震动 | 粗略，多盘机器分不清谁在转 |
| 后台看状态 | 飞牛在存储管理里看盘状态，群晖在存储管理器看 | 直观但只能看"当下"这一秒 |
| 查启停次数 | SSH进去跑smartctl，对比睡前和早上的计数 | 硬证据，夜里被叫醒几次全记录在案 |
第三个办法是关键。开SSH后跑这条命令：
smartctl -a /dev/sdb | grep -iE "Start_Stop|Load_Cycle|Power_On"
Start_Stop_Count是马达启停计数，Load_Cycle_Count是磁头归位计数。睡前记一次数，早上起来再看一次，两个数都涨了，说明硬盘夜里睡了又被反复叫醒；数字纹丝不动，说明它压根就没睡过。我那晚睡前记的是启停1867次，早上起来一看1912次——一晚上启停45次，平均每20分钟一轮，这哪是休眠，这是给硬盘上夜班。
系统盘睡不了是正常的，先分清哪块盘该睡
很多人在这一步就走偏了。先说结论：系统盘不睡是正常的，别在它身上浪费时间。
我家这台N100小主机装飞牛OS，一根256G的NVMe固态跑系统，两块4T西数红盘做数据盘。飞牛的系统日志、数据库、Docker根目录全在固态上，机械盘上只有影视和备份文件，这种结构里机械盘才有睡的可能。如果你的系统和数据挤在同一块机械盘上，系统每隔几分钟写点日志，这块盘基本告别休眠了，要么忍，要么加一根便宜的固态把系统迁走。
群晖用户要多知道一件事：DSM的系统分区是镜像分布在每一块盘上的，系统日志一写，理论上会碰所有盘。所以群晖的休眠出名地难伺候，官方论坛一堆"DS923+休眠失败"的帖子根子都在这。这不是你设置错了，是架构就这样。能做的把能挪的负载都挪走，剩下的看运气。
头号嫌疑：Docker容器，十个有八个是它
如果你跟我一样装了一堆Docker容器，先查这里，命中率最高。我挨个说：
qBittorrent，我那晚的真凶。哪怕下载速度是0、一个种都没在做，它每隔几分钟也会把session文件和做种状态flush一次到配置目录。我当初把配置目录挂在机械盘上，就是这个行为把盘每5分钟戳醒一次。处理办法：配置目录、watch目录全挪去固态，只有下载落盘的路径留在机械盘——下载的时候反正盘是醒的，不冲突。
Jellyfin之类的影音服务，查转码临时目录挂在了哪。我装Jellyfin那篇里转码路径如果写在机械盘，看片的时候转码碎片文件会疯狂写盘——看片时盘醒着无所谓，怕的是有人把缓存目录设在了数据盘还挂着常驻服务。
监控类容器，Uptime Kuma、各类拨测工具。它们的历史数据是个SQLite文件，每几分钟落一次盘。文件不大，但足够把刚睡下的盘叫起来。同样挪固态。
Docker自身的日志。容器往stdout打的每一行日志，Docker都默认用json-file驱动写进宿主机的Docker根目录。要是你的Docker根目录在机械盘上，一个话痨容器能把盘写个没完。docker inspect容器名，看LogConfig那段的路径落在哪块盘。
排查方法笨但有效：docker ps拿到容器清单，一半一半地stop，每停一批等15分钟看一次盘状态，二分三次就能锁定。我嫌等15分钟太慢，是直接看的下一步的iotop记录。
第二梯队：索引、定时任务和系统自身的动作
Docker排除了再查这些，按嫌疑大小排：
相册索引。群晖的Synology Photos、飞牛的相册应用，刚导入几万张照片后会连续几天在后台生成缩略图和特征索引，这期间硬盘休眠想都别想，属于正常现象，跑完就消停。判断方法：看相册应用里索引进度是不是100%。
定时备份任务。我用rsync每天凌晨两点把重要目录按备份策略往第二块盘上抄一份——任务本身没毛病，但它每天固定把你叫醒一次，属于合理唤醒，不用管。
计划任务里的SMART检测。群晖默认有个定期的硬盘SMART快速测试，很多人不知道它存在。SMART测试必须盘醒着才能测，等于系统定期亲手把你硬盘摇醒。控制面板、任务计划里找到它，要么关掉要么把频率降到一月一次。
日志轮转。/var/log下的logrotate一般半夜动手，量很小，通常不构成主因，但群晖那种系统分区跨盘的架构下它会牵连所有盘。
我的一晚上：用iotop蹲出真凶
上面说的都是"嫌疑犯画像"，真正定罪靠抓现行。飞牛开SSH，root下跑这个：
iotop -o -b -n 3 > /tmp/io.log
-o只显示有实际读写的进程，-b跑三轮就退出。麻烦在于写入是间歇性的，你跑的那三秒它可能正好在睡觉。我写了个死循环，每分钟采一轮，输出丢在固态上，睡前挂上早上收网：
while true; do date >> /tmp/io.log; iotop -o -b -n 2 >> /tmp/io.log; sleep 60; done
早上一翻日志，凶手清清楚楚：凌晨1点17分起，qBittorrent每5分钟一次对/vol1/docker/qbittorrent的小量写入；3点02分是我自己那条rsync备份的固定动作；4点半有一次dockerd的日志轮转。没有别的了——相册索引早就建完，Jellyfin转码目录在固态，监控容器压根没装。
处理就三步：qBittorrent整个配置目录挪到固态的Docker目录下，容器重建（数据都在挂载目录里，十分钟搞定）；rsync那次唤醒认了，合理的；日志轮转量太小无视。第二天晚上再测，Start_Stop一夜只涨3次——一次rsync，两次没查出来的零星唤醒，11瓦的深度待机整晚，这才叫休眠。
修完还是不睡？有些情况就该接受
最后把"哪些盘值得折腾"说清楚，别为省几度电把日子过反了：
| 使用场景 | 该不该指望休眠 | 怎么办 |
| 系统盘（尤其机械） | 不指望 | 加固态迁系统，一劳永逸 |
| 纯仓库盘（影视/备份归档） | 最有价值 | 按上面顺序排查，多半能睡 |
| 下载机常驻做种 | 基本没戏 | 直接关休眠，下完挪走再睡 |
| 监控录像盘 | 没戏 | 关休眠，7x24写是本职工作 |
再泼盆冷水。有人休眠失败就焦虑硬盘寿命，其实3.5寸机械盘的启停设计寿命普遍在5万次量级，就算一晚40次，一年也就1.5万次，而且 Load_Cycle 磁头归位计数很多盘标称60万次。真正的伤盘大户是高温和震动，不是这种浅睡浅醒。休眠一年省的电费按电费那篇的口径也就50块出头，为它熬一晚上值得，为它天天惦记不值。排查一遍，能睡就睡，睡不了拉倒，硬盘比你想象的结实。
发表评论