IntelliParkとは
Western Digital社のHDDには、IntelliParkという機能があり、一定時間アクセスが無かった時に、ヘッドを退避させるといものだ。公式な情報ではないが、WD BlueのWD80EAAZという8TBモデルでは、8秒間アクセスが無かった時に、退避すると言われている。
目的の一つは省電力で、もう一つは退避している時に強い衝撃を受けてもディスクとヘッドが衝突せず安全だという。使用頻度の低いHDDであれば、その恩恵はあるだろう。
アクセスが無かった時にヘッドが退避するまでの時間は、モデルによって異なるらしく、これはHDDのファームに設定されているのだが、設定をコントロールできるものとできないものがあるのだ。
IntelliPark問題
このBLUEのWD80EAAZというHDDは、そもそもサーバーやNASなどへの搭載は推奨されていない。WDには現在、Blue、Red、Purple、Goldのタイプがあり、Blueはパーソナル、RedはNAS、Purpleは24時間監視など、Goldは最高品質となっている。
品質が高い方がもちろん良いけれど、品質が上がるほど値段もぐんと上がる。NASと言っても個人で運用していれば、24時間過酷に使うわけではない。安いHDDでも十分だと考えるのは人情である。
筆者はこのWD80EAAZをSynologyのNASに2台搭載した。何かしら対処法はあるだろうと高をくくっていた。
ここで、気になるのは、メーカーのサイトでは「ロード/アンロードサイクル 300,000」と書かれていることだ。WDが言う「30万回」というのは、製品仕様書の「設計上の期待値・耐久性能の目安」と考えられる。保証の条件は、2年となっていて、ロードアンロードサイクルは条件ではない。しかし、「異常使用」として高負荷が与えられていたことを根拠に保証対応が拒否される可能性もないとは言い切れない。
ユーザーの対応としては大きく2種類だ。「30万回越えを避ける」のか「30万回越えても気にしない」のか。
WD Red以上を売るためにBlueを過小評価していることも考えられるが、それでは他社との競争で不利になる。
やはり重要なことは、30万回越えが本当に問題ないのならば、メーカーはわざわざ耐久性能の目安として「ロード/アンロードサイクル 300,000」を明記しないだろう。やはり30万回を超えないようにする対策は必要だと考える。
IntelliPark回避策について
本記事が対象としているのは、主にSynology NASである。データはRAID1相当で二重化している。HDDが1本壊れてもデータは復旧できるのでリスクは軽減されている。
またSynologyのベースはLinuxであるが、詳細は不明だがrawレベルのアクセスに制限が掛けられているようでもあり、純粋なLinuxとはまた異なるようだ。危険な変更もやりたくない。
IntelliParkを回避するには、いくつかの対策がある。AIにも協力してもらった。
１．hdparm ～APM (Advanced Power Management)
hdparmでHDDのアイドルなどを調整する方法。
$ sudo hdparm -B 254 /dev/sda
-B 254 でパークを抑制（255だとAPM完全無効化）
再起動でリセットされるので起動時に実行する設定が必要
２．WDIDLE3 ～当初WDから配布されたアプリ
IntelliPark自体を無効化するためのツール
３．ATAコマンドでNOPを定期送信
一定間隔でSATAにNOPを送るとアイドル状態がキャンセルされ、IntelliParkが発動しないという記事があった。HDDに読み書きせずにIntelliParkだけを止められれば完璧だ。
https://woremacx.com/post/2024/reduce-load-cycle-count-increase-on-hdds-with-intelli-park/
４．ATAコマンドでNOP以外を定期送信
上記NOPに類する方法で、IDENTIFY、READ VERIFYを定期送信
IntelliParkを回避できるかは未確認
５．ddを定期送信
データをコピーして格納するユーティリティを定期実行
６．touchで特定ファイルを定期更新
特定のファイルのタイムコードだけを最新化するコマンドを定期実行https://ktakahashi0727.jimdofree.com/%E3%83%96%E3%83%AD%E3%82%B0-20250312/
回避策についての検証
１．hdparm ～APM (Advanced Power Management) を調整
$ sudo hdparm -B 255 /dev/sda
を実行すると、
/dev/sda:
setting Advanced Power Management level to disabled
HDIO_DRIVE_CMD failed: Input/output error
APM_level = not supported
理由は不明だが、成功はしなかった。-B 255でなく、-B 254でも同様の結果だった。そもそも、こんなに簡単だったら誰も苦労はせず、IntelliPark問題とも言われるわけがない。でも念のため検証した。
２．WDIDLE3 ～当初WDから配布されたアプリ
これも多くの方々がWD80EAAZで実施され、不成功だったことが多数報告されている。1件の成功事例も目にしたことは無い。よく似たモデル名のWD80EAZZとは異なるのだ。検証は省略する。
３．ATAコマンドでNOPを定期送信
NOPを定期送信するとアイドル状態がキャンセルされ、IntelliParkが発動しないのであれば、HDDへの読み書きが発生しないので完璧な方法だ。この記事によれば、コードを作って、何やらコンテナに載せて・・・と実装方法が大変に難しい。成功しているらしい。素晴らしい。
https://woremacx.com/post/2024/reduce-load-cycle-count-increase-on-hdds-with-intelli-park/
ストレートにコマンドラインから実行できる命令を書けないものか？
調べてみると、sg_rawというコマンドが、SATAへのダイレクトな命令であり、これが使えそうだ。ATA PASS-THROUGH(16)のコマンドを送信する。
結論から言うと以下の方法はどれも成功しなかった。それでも経過を報告しておく。
まずは基本構文：
sudo sg_raw /dev/sda 85 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00
とすると、
SCSI Status: Check Condition
Sense Information:
Descriptor format, current; Sense key: Aborted Command
Additional sense: No additional sense information
Descriptor type: ATA Status Return: extend=0 error=0x0
count=0xb0 lba=0x36c258 device=0x40 status=0x40
AIによれば、「status=0x40, error=0x0 なので、致命的なATAエラーはないく、コマンド自体はデバイスに届いてはいるが、**SCSIとしては Check Condition（＝異常応答）**が返ってきているため、Linux 側としては「成功した」とは見なしていません。」とのこと。
今度は、AIのサジェスチョンを受けて、コードを少し変えて送信。
sudo sg_raw /dev/sda 85 08 00 00 00 00 00 00 00 00 00 00 40 00 00 00
SCSI Status: Check Condition
Sense Information:
Descriptor format, current; Sense key: Aborted Command
Additional sense: No additional sense information
Descriptor type: ATA Status Return: extend=0 error=0x0
count=0x0 lba=0x000000 device=0xa0 status=0x50
次にNOPそのものに再チャレンジ
sudo sg_raw /dev/sda 85 08 00 00 00 00 00 00 00 00 00 a0 00 00 00
この結果は↓
NVMe Result=0x2
結果が変わった。
「NVMe Result=0x2」の意味
このメッセージが出たということは：
実際のドライブはSATAではなく NVMe（あるいはUSB-NVMeブリッジ）として認識されている。つまり sg_raw は ATAコマンドを送ろうとしているけど、デバイスはNVMeだから通じていない状態？
これ以上は理解できないので、NOP以外の方法にもチャレンジすることにした。
４．ATAコマンドでNOP以外を定期送信
「IDENTIFY DEVICE」
NOP以外にもSATAにアクセスするコマンドが効かないかどうかを調べてみる。「NOP」ではなく「IDENTIFY DEVICE」を試す。
sudo sg_raw /dev/sda 85 08 00 00 00 00 00 00 00 00 00 00 40 EC 00 00
SCSI Status: Check Condition
Sense Information:
Descriptor format, current; Sense key: Aborted Command
Additional sense: No additional sense information
Descriptor type: ATA Status Return: extend=0 error=0x0
count=0x0 lba=0x000000 device=0xa0 status=0x50
というレスポンスが帰ってきた。
コマンドは届いているけれど実行されていない/拒否されている可能性が高い。
次は「READ VERIFY」という方法。
sudo sg_raw /dev/sda 85 08 00 01 00 00 00 00 00 00 00 00 40 40 00 00
SCSI Status: Check Condition
Sense Information:
Descriptor format, current; Sense key: Aborted Command
Additional sense: No additional sense information
Descriptor type: ATA Status Return: extend=0 error=0x0
count=0x0 lba=0x000000 device=0xa0 status=0x50
いかにもエンジニアっぽい表現をするAIの説明によれば、
「いずれのコマンドも status=0x50（DRDY + DSC） → ATA的には「成功」っぽく見える。
でも SCSI層が Check Condition（=異常）を返している → 「ATAとしてはOKだけど、SCSI的には何か不備がある」ケース。
このパターン、よくある「ATA PASS-THROUGHコマンドが正しく受け入れられても、SCSI層で誤解釈されてしまう」やつです。」
「Synology系カーネルがATAパススルーを制限している」可能性が指摘された。
また、未確認だけれど、ATAパススルーコマンドがうまく行って、実行できた場合には、synology側にログが発生する可能性もある。ディスクが再認識されましたとか、いかにもありそう。不要に大量なログが出ないよう配慮が要るかもしれない。
でも、それよりも何よりも、もしATAコマンドがうまく行ったら、その方法を教えてください。
５．ddを定期送信
データをコピーするユーティリティーddを使用してみる。
sudo /bin/dd if=/dev/sda of=/dev/null bs=512 count=1 iflag=direct
1+0 records in
1+0 records out
512 bytes copied, 0.0055265 s, 92.6 kB/s
という結果が出た。コマンドは正しく実行できている。
これをcronで回せば自動実行はできる。
６．touchで特定ファイルを定期更新
ddならtouchの方が軽いのではないかとも思う。既存ファイルに対してはタイムスタンプだけを最新化するので、ddやファイルコピーよりもかるいのではないか？
https://ktakahashi0727.jimdofree.com/%E3%83%96%E3%83%AD%E3%82%B0-20250312/
この記事でもtouchが利用されている。ここで紹介されているscriptでは仮想にログを書き出したり丁寧なつくりである。
最低限度に縮めると次のようになるだろう。下記内容でkeepalive.shを作って実行すれば良い。
#!/bin/bash
while true; do
touch “/xxx/yyy/.keepalive”
sleep 9
done
sshでログインして、末尾に & を付けて実行すればバックグラウンド実行する。
$ /bin/bash /xxx/yyy/keepalive.sh &
再起動したら、sshから再度実行するか。起動したら実行するようにしておく。この例では、9秒毎のtouchとしている。7秒は完璧だけれども、9秒でもほとんど増えなかった。（しかし実行間隔の設定はまだまだ検証の余地がある。）
このscriptを停止する方法も念のために書いておく。
1) SSHでプロンプトから、ps -auxを打つ
2) /bin/bash /xxx/yyy/keepalive.shのプロセスID（PID）を探す
3) kill PID
採用したIntelliPark回避策
うまく行った方法で一番軽そうなのは、今のところtouch方式なので、この方法を採用した。
上記の例では、9秒間隔にしたけれど、NASが連続で読み込み/書き込みで使われている時は、さして問題は無い。問題は未使用時間にHDDがアイドルできずにずっと動き続けることによる消耗である。
HDDの寿命がどれくらいかは使い方にも環境にもよるので、一概に言えないが、どれくらいを目指せばよいか目標を立てて考えて行くしかない。
Load Cycle Countが、
1日に80回なら、1年で2万9200回、30万回に達するまで約10年。
1日に200回ならば、1年で7万3000回、30万回までは約4年。
1日に400回だと、1年で14万6000回、30万回までは約2年。
HDDの消耗を抑える対策も必要
ネットで見ると、HDDの寿命は、3～4年とか、26000時間から35000時間と書かれているサイトが多い。ちなみにWDのBlueは2年保証、RedとPurpleは3年保証で、Goldは5年保証である。
PCに搭載していれば、夜寝る時に電源を切ってしまえばよいのでその間はHDDもお休みできる。NASだと何もアクセスが無くても時々なぜだか動いているので、これで使用時間が若干増えることになる。
利用者がアクセスしない時間帯のHDD稼働時間とロードアンロードサイクルカウントについてもまだよく分かっていない。
ロードアンロードサイクルカウントが与える負荷と連続稼働時間による負荷など、消耗のリスクを総合的に把握して考える必要がある。