那台跑了KeyarchOS的服务器，装了好几块机械数据盘，平时业务进程集中在系统盘上，数据盘大半时间都处于“没人读也没人写”的状态。这个忙等着监控面板的时候我看了一下温度，发现这些空闲盘的温度甚至比一直在读写的盘还高。查了一圈，KeyarchOS默认软件源里没有现成的磁盘待机工具，最终我把hd-idle-1.05-4手动适配了进来。这篇文章就把整个适配过程包括源码编译、systemd服务化、开机自启、验证和排障完整记录下来，给同样在KeyarchOS以及其他RPM系发行版上做存储节点维护的朋友做个参考。
这类工具不算复杂，但适配过程里藏着不少细节。系统盘不能随便待机、数据盘的空闲超时要按访问规律调、SMART命令能不能穿透磁盘阵列卡，每一个问题都会直接影响效果。下面我从背景开始，把这次适配逻辑和技术方案都拆开讲清楚。
1. 背景：KeyarchOS上为什么要适配hd-idle
1.1 磁盘空闲放任不管的代价
机械硬盘在设计上并没有“自动休眠”这一说，你插上电源让它转，它就会一直以额定转速旋转。对于一台以数据存储为主的服务器，数据盘经常处于“上一次访问在一小时前”的状态，可磁盘本身并不知道自己可以休息。
这种情况下浪费的不只是那点功耗。长时间全速空转会持续产生热量，机箱里的风道如果设计得也不太好，磁盘温度会明显升高。温度对机械盘寿命的影响不是玄学，电子元器件的老化速度、轴承润滑脂的衰减，都跟温度直接相关。
有人可能说，那我不用的时候就关机或者拔盘不就行了？但在实际存储架构里，这些盘需要保持在线状态，供其他机器随时读取数据，不可能因为暂时没有访问就物理断电。正确的做法是让磁盘进入待机状态，把电机停下来，转速降到0，等下一次真正需要访问的时候再唤醒。
1.2 为什么选hd-idle而不是hdparm
很多Linux老用户第一反应是用hdparm，一条hdparm -S 120 /dev/sda就能设置磁盘在120秒无操作后进入待机。这个方案的问题在于它是“一次设置、不再管理”的，缺少对磁盘状态动态变化、按磁盘单独设定超时、长期自动化检查这些能力。
hd-idle专门干这件事，它会作为一个常驻后台服务运行，按固定周期检查所有登记过的磁盘，记录每块盘的访问时间，一旦发现某块盘的连续空闲时间超过阈值，就通过ATA的SMART命令把磁盘切换到待机模式。
hd-idle-1.05-4这个版本是上游比较成熟的一版，支持常见的SATA/SCSI盘的SMART透传，也可以针对具体磁盘单独设置参数。在KeyarchOS这种默认没有收录该工具的发行版上，它比hdparm加crontab的方案要省心得多。
1.3 这次适配的具体目标
所谓的“适配”，说得直白一点就是让一个本来不在KeyarchOS默认软件仓库里的开源工具，能够在当前系统环境下完成编译、安装，并按照系统的服务管理规范跑起来。
具体拆成四件事：源码编译、二进制安装、systemd服务化、实际效果验证。编译解决的是“能不能跑”的问题，服务化解决的是“怎么长期跑”的问题，验证解决的是“跑起来有没有用”的问题。下面按这个顺序一步步来。
2. 适配前准备：环境检查与编译环境搭建
2.1 确认KeyarchOS版本和仓库状态
动手之前先搞清楚系统底细。KeyarchOS虽然和常见的RHEL系发行版一样使用RPM包管理，但不同小版本的软件仓库内容、默认GCC版本都会有差异。
cat /etc/os-release uname -a dnf repolist这三条命令分别看发行版信息、内核版本和当前可用软件源。我这次操作的机器是KeyarchOS的较新版本，内核版本也比较新，软件源本身是最小化配置，能够正常用dnf install装基础包，但确实搜不到hd-idle相关的内容。
这个环节最需要注意的是：别急着换源或者手动下载其他发行版的二进制RPM包。RPM包虽然都是RPM格式，但依赖库版本、启动脚本路径、服务单元写法都可能不一样，跨发行版直接安装容易埋坑。从源码在当前系统上编译，行为最可控。
2.2 安装编译工具链和基础依赖
hd-idle的源码就是一个C程序，编译依赖很简单，不需要额外的第三方库。系统里如果是最小化安装，一般需要补上GCC和Make。
dnf install -y gcc make which gcc which make我习惯顺手再确认一下rpm-build是否可用，因为后面想把二进制打成RPM包时会用到。如果没有也没关系，不影响先跑通程序。
dnf install -y rpm-build安装完成后再看dnf list installed | grep -E 'gcc|make'，确认版本号存在就行。这里不需要纠结GCC版本新旧，后面源码编译阶段遇到兼容问题再处理。
2.3 拿到hd-idle-1.05-4源码
接着就是获取源码包。hd-idle-1.05-4的上游发布形式通常是tar.gz源码包，也可能是对应的SRPM包。如果是SRPM，解包之后看到的依然是源码目录结构；如果是直接源码包，解压之后就能看到hd-idle.c、Makefile等文件。
tar -xzf hd-idle-1.05-4.tar.gz cd hd-idle-1.05-4 ls -l目录里核心文件其实就那么几个：C源码文件、Makefile、README、man手册。看到这个结构就心里有数了，这不是一个需要./configure的复杂项目，就是一个传统的、可以在几分钟内手工完成编译的小工具。
3. 编译安装：把源码变成可执行文件
3.1 快速认识hd-idle源码结构
hd-idle的核心逻辑不复杂，主程序维护一张磁盘状态表，定时轮询每块盘的设备号，通过ioctl或SMART命令查询最后一次访问时间，超过设定阈值就发送待机指令。整个程序不依赖大型框架，和内核的交互通过标准Linux块设备接口完成，所以源码目录里才只有这么几个文件。
源文件里最容易让新人困惑的是那些参数解析代码，全部写在main()里。建议第一次接触的人直接把man手册过一遍，重点看参数表，不需要逐行读源码。我自己的习惯是先编译，编过了再看行为，毕竟这种老牌工具的上游代码通常已经经过了大量生产环境验证。
3.2 用make完成编译
在KeyarchOS上编译这种传统C项目，最标准的操作就是直接执行make。不要上来就改Makefile，先让它在默认配置下跑一遍，看报错再处理。
make编译顺利的话，当前目录下会生成一个名为hd-idle的可执行文件。用file hd-idle检查一下，能看到类似ELF 64-bit LSB executable的输出，说明二进制格式匹配当前系统。
我这次在KeyarchOS上编译时，第一遍就报了警告，但二进制还是出来了。这里提醒一句：警告可以看，不重要的小警告可以先忽略，真正要处理的是error级别的报错。
3.3 老代码在新编译器下的兼容处理
hd-idle-1.05这种年代比较久的代码，放到新GCC环境下编译，最典型的问题是两个：函数隐式声明、某些宏没有定义。我在这次适配中遇到的是implicit declaration of function 'daemon'这类报错，看起来唬人，实际原因很简单——新版GCC默认采用更严格的C标准，老代码里少了一行头文件包含。
解决方式有两种，任选其一：
第一种，编译时加宏定义，告诉编译器按GNU标准去处理：
make CFLAGS="-O2 -Wall -D_GNU_SOURCE"第二种，修改源码，在文件头部补上必要的头文件引用：
#include <unistd.h> #include <syslog.h>改成哪种都行。我的习惯是优先用编译参数解决，保留源码原样，这样以后对照上游代码做版本升级的时候更省事。如果你在编译时遇到的报错和我不同，比如提示缺少某个头文件，可以先看报错信息里提到的函数是什么，再到头文件目录里搜一下，大部分都能用补include的方式解决。
3.4 安装路径选择与权限
hd-idle需要root权限运行，二进制要放在普通用户也能执行、但不建议随便改动的路径。KeyarchOS和多数RHEL系发行版一样，/usr/local/sbin就是给本地自编译系统管理工具准备的。
install -Dm755 hd-idle /usr/local/sbin/hd-idle install -Dm644 hd-idle.8 /usr/share/man/man8/hd-idle.8 mandb第一条命令把二进制放到/usr/local/sbin并设置755权限，第二条把man手册放到系统man目录，第三条更新文档索引。这样操作之后，系统内执行hd-idle甚至man hd-idle都能直接找到。
我没有选择把二进制放到/usr/bin或/usr/sbin，原因是这两个目录通常归软件包管理器管，本地手工安装的文件放进去容易被后续的操作意外覆盖。/usr/local前缀本来就是给本地安装留的，语义清晰。
4. 用systemd把hd-idle变成开机服务
4.1 服务文件怎么写得清楚又稳定
二进制编译出来了，只算完成一半。每一个长期运行的守护进程都应该交给systemd管理，这样才能获得开机自启、崩溃重启、日志统一采集这些现代Linux服务管理能力。
我在/etc/systemd/system/下创建了hd-idle.service：
[Unit] Description=hd-idle disk standby service After=local-fs.target [Service] Type=simple ExecStart=/usr/local/sbin/hd-idle -a sda -i 600 -a sdb -i 1800 -c 60 Restart=on-failure [Install] WantedBy=multi-user.target这里用Type=simple，因为hd-idle默认就是前台常驻运行，不会自己fork成后台进程。systemd对simple类型的服务管理最直接，进程退出就能立刻感知。Restart=on-failure表示只有异常退出才自动拉起，避免手工停服务的时候又被拉起来。
配置参数直接写在ExecStart里，这样最直观。如果以后想改参数，编辑这个文件再执行systemctl daemon-reload就行。
也有一种做法是单独建一个环境文件，用EnvironmentFile加载参数。这个方式确实更灵活，但有一个坑：systemd环境变量的解析规则和shell不一样，参数里如果带引号或者通配符，容易出现预料之外的行为。我实际用下来，参数不频繁变动的情况下，还是直接写在ExecStart里最省心。
4.2 hd-idle常用参数和我推荐配置
hd-idle的全部参数以-a为核心，-a用来指定接下来参数生效的磁盘范围，后面的参数只作用于这个范围内。我常用的参数集中在下面这几个：
| 参数 | 作用 | 使用示例 |
|---|---|---|
-a | 指定磁盘或分组，all表示所有磁盘 | -a sda |
-i | 空闲多少秒后进入待机，0表示不待机 | -i 600 |
-b | 开机后多少秒内不检查待机，留出系统初始化时间 | -b 300 |
-c | 主检查周期，每隔多少秒检查一次所有磁盘 | -c 60 |
-d | 开启调试模式，输出详细日志 | -d |
-f | 指定日志文件路径，不指定则走syslog | -f /var/log/hd-idle.log |
针对这次适配的场景，我给数据盘定的策略是：系统盘完全不参与待机，因为系统盘随时可能有日志、临时文件写入，频繁待机反而会增加唤醒次数；两块纯数据盘一块设置为10分钟空闲待机，另一块访问频率更高的设置为30分钟。
对应的命令行就是：
/usr/local/sbin/hd-idle -a sda -i 0 -a sdb -i 600 -a sdc -i 1800 -c 60这条命令里-a sda -i 0先把sda设为“永不待机”，然后-a sdb -i 600把后面的参数对象切到sdb，-a sdc -i 1800再切到sdc。参数顺序是有讲究的，每次遇到新的-a，后续的-i就作用于新的对象。
4.3 启动、开机自启和常见service坑
服务文件写好后，执行以下命令让systemd重新加载并启动服务：
systemctl daemon-reload systemctl enable --now hd-idle systemctl status hd-idle看到active (running)就说明服务本身起来了。enable --now同时完成开机自启和立即启动，比分开执行两条命令省事。
这一环节最常见的坑是服务起不来的场景。如果systemctl status显示ExecStart路径找不到，大概率是二进制没有安装到unit文件里写的路径，用whereis hd-idle确认一下实际路径，保持一致就好。如果是权限问题，确认二进制当前属主是不是root，/usr/local/sbin下的文件至少要是root可执行。
还有一点容易被忽略：daemon-reload记得执行。systemd会缓存服务定义，修改了service文件不重载就去重启，生效的很可能还是旧配置。
5. 验证效果与问题排查
5.1 先看日志：hd-idle到底在忙什么
服务跑起来不代表真的生效，需要看日志确认行为符合预期。查看方式：
journalctl -u hd-idle -f如果开启了-d调试模式，能看到类似下面的轮询记录：
Mar 02 10:30:01 keyarchos hd-idle[1234]: checking sda ... ok Mar 02 10:30:01 keyarchos hd-idle[1234]: sda is active, reset idle counter Mar 02 10:31:01 keyarchos hd-idle[1234]: checking sdb ... ok Mar 02 10:31:01 keyarchos hd-idle[1234]: sdb idle for 611 seconds, sending standby command出现idle for ... seconds说明hd-idle确实在监控；出现sending standby command说明它已经在真正执行待机操作。
这里的重点不是死记日志内容，而是理解行为：checking说明检查周期在走，active说明磁盘有活动被捕获，standby说明超时逻辑被触发。完整看到这几种状态，工具才算是真正在工作。
5.2 用hdparm和smartctl确认磁盘状态
日志说发了待机命令，实际盘有没有进去，要靠磁盘状态检测命令来验证。我最常用的命令是hdparm：
hdparm -C /dev/sdb正常待机时输出里会出现：
/dev/sdb: drive state is: standby如果盘还在空转，输出则是active/idle。注意这个命令本身不会唤醒待机盘，可以放心反复执行。
另外smartmontools自带的检查命令也很有用：
smartctl -n standby /dev/sdb当磁盘处于standby状态时，这个命令会返回一个非零退出码，并提示当前处于待机模式。看到这个结果就说明待机逻辑验证闭环了。
5.3 真实使用中会遇到的坑
这里说几个我在实际部署过程中踩过和见过的坑，每一个都是实打实的经验教训。
第一个坑：把系统盘也纳入了待机管理。系统盘的写入频率远比数据盘高，一旦系统盘进入待机，频繁的日志写入、临时文件操作都会触发磁盘唤醒，结果就是盘在很短的时间内反复“待机→唤醒→再待机”，这对机械盘的损伤比一直转着更大。系统盘一定不要设待机参数。
第二个坑：待机超时设置太短。机械盘从待机恢复到可读写状态，需要几秒的启动时间，如果应用层没有做超时重试逻辑，一次磁盘唤醒就可能引发一连串I/O错误。数据盘的空闲阈值建议从600秒起步，不要为了省电把时间压到几十秒。
第三个坑：磁盘阵列卡或USB外接盘柜上传SMART命令失效。hd-idle依赖SMART命令把盘切到待机状态，如果RAID卡把磁盘的ATA命令透传屏蔽了，那么日志里会看到SMART相关的错误，工具等于空转。这种情况下需要先确认磁盘是直通模式，或者改用其他方案。
第四个坑：日志里大量sda is active刷屏。这通常意味着某个后台任务在周期性读取这块盘，比如监控采集、日志清理、备份扫描。可以先临时停掉工具，用iostat -x 1或lsof +D排查到底是哪个进程在访问。
5.4 常见问题速查表
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
make报隐式声明错误 | 高版本GCC标准更严格 | 加-D_GNU_SOURCE或补头文件include |
| 服务启动失败，提示路径不存在 | unit文件里ExecStart路径不对 | 用whereis hd-idle确认实际路径 |
| 启动成功但磁盘不待机 | 目标盘没有配置-a规则 | 检查ExecStart参数，确认-a后跟的是正确盘符 |
| 日志出现SMART错误 | RAID卡/USB桥接不支持SMART透传 | 改为直通模式，或在其他环境验证 |
| 磁盘频繁唤醒 | 后台任务周期访问盘 | 用iostat/lsof定位并处理访问源 |
| 重启后服务没了 | 没有执行enable | 执行systemctl enable hd-idle |
6. 后续优化与个人心得
6.1 建议顺手打成RPM包
二进制和服务文件都已经验证没问题了，我建议花几分钟把整个东西打成RPM包。这样后续在其他KeyarchOS节点上装的时候，一条dnf install就能解决，不用重新编译。
最低限度的spec文件大概长这样：
Name: hd-idle Version: 1.05 Release: 4 Summary: Run hd-idle IDE hard disk idle daemon License: GPLv2+ Source0: hd-idle-1.05-4.tar.gz %description hd-idle is a disk standby utility for Linux. %prep %setup -q %build make CFLAGS="-O2 -Wall -D_GNU_SOURCE" %install install -Dm755 hd-idle %{buildroot}%{_sbindir}/hd-idle install -Dm644 hd-idle.8 %{buildroot}%{_mandir}/man8/hd-idle.8 %files %{_sbindir}/hd-idle %{_mandir}/man8/hd-idle.8 %post systemctl daemon-reload || true %postun systemctl daemon-reload || true这个spec只是一个骨架，真正要发布的时候还需要加服务单元文件的打包和更多细节。但有了这个雏形，后续不管是在本机还是放到内部软件源里，都比现编译要高效得多。
6.2 我最后想说的几条经验
老工具适配到新系统，最忌讳的是遇到编译报错就慌。hd-idle这类源码干净的小工具，80%的编译问题都是头文件包含和编译标准导致，解决方式就那么几种，别随便改代码逻辑。
另外一点，工具跑通只是第一步，真正的功夫在参数调优上。我见过不少人在配置里把所有盘都设成600秒待机，结果系统盘每天晚上反复唤醒，监控面板看着一片红。开始的时候宁可保守一点，把系统盘排除、把数据盘超时调长，观察一周实际访问规律之后再逐步缩短空闲阈值。
机械盘待机本来就是省电和寿命之间的权衡。频繁启停带来的机械损耗，可能比一直空转更伤盘。适配工具是手段，让盘在合适的时间休息才是目的。我现在的做法是：业务盘绝不待机，冷数据盘超时设置在30分钟以上，并且定期用smartctl检查磁盘SMART健康属性，确保这个机制没有对硬盘寿命造成反向影响。这套配置已经在KeyarchOS上跑了挺长时间，整体看下来，温度降了，异常告警也少了很多。
