IntelliParkとは
Western Digital社のHDDには、IntelliParkという機能があり、一定時間アクセスが無かった時に、ヘッドを退避させるというものだ。
本来の目的は、省電力で、もう一つは退避している時に強い衝撃を受けてもディスクとヘッドが衝突せず安全だという。
WD Green→Blueへの移行期に、既にIntelliParkという用語は使用されなくなったが、機能はそのまま継続したという経緯があった。WDIDLE3というツールからその機能を確認でき、そして無効化することもできた。
一部のレビューサイトでは「WD80EAAZにはIntelliPark機能が搭載されていない」とする意見も見受けられたが、これに関する明確なエビデンスは確認できておらず、また同様の主張は他にほとんど見られない。
一方で、実際にこのモデルを使用した多くのユーザーが「ロード・アンロードサイクルが短時間で数百回増加する」という報告をしており、これは従来のIntelliParkと同様の挙動を示している。
よって、本稿ではIntelliParkまたはそれと同等の自動ヘッド退避機能がWD80EAAZに実装されていると判断する方が合理的と考える。
以前のモデル(モデル名が良く似ていて大変にまぎらわしいのだが)WD80EAZZでは、8秒間アクセスが無かった時に退避する設定になっていた。
公式な情報にはIntelliParkという言葉は無いが、秒単位で自動的にヘッドを退避させる機能は確かに継承されている。WD80EAAZという8TBモデルにおいても秒単位でのヘッド退避の機能が実装されている。
アクセスが無かった時にヘッドが退避するまでの時間は、モデルによって異なるらしく、これはHDDのファームに設定されているのだが、設定をコントロールできるものとできないものがあるのだ。
WD80EAAZのスペックを記しておく。
モデルファミリー:Western Digital Blue (CMR)
フォームファクター:3.5 inches
インターフェイス:SATA
回転数:5640 RPM
記録方式:CMR
キャッシュサイズ:256 MB
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にも協力してもらった。
1.hdparm ~APM (Advanced Power Management)
hdparmでHDDのアイドルなどを調整する方法。
$ sudo hdparm -B 254 /dev/sda
-B 254 でパークを抑制(255だとAPM完全無効化)
再起動でリセットされるので起動時に実行する設定が必要
2.WDIDLE3 ~当初WDから配布されたアプリ
IntelliPark自体を無効化するためのツール
3.ATAコマンドでNOPを定期送信
一定間隔でSATAにNOPを送るとアイドル状態がキャンセルされ、IntelliParkが発動しないという記事があった。HDDに読み書きせずにIntelliParkだけを止められれば完璧だ。
https://woremacx.com/post/2024/reduce-load-cycle-count-increase-on-hdds-with-intelli-park/
4.ATAコマンドでNOP以外を定期送信
上記NOPに類する方法で、IDENTIFY、READ VERIFYを定期送信
IntelliParkを回避できるかは未確認
5.ddを定期送信
データをコピーして格納するユーティリティを定期実行
6.touchで特定ファイルを定期更新
特定のファイルのタイムコードだけを最新化するコマンドを定期実行https://ktakahashi0727.jimdofree.com/%E3%83%96%E3%83%AD%E3%82%B0-20250312/
回避策についての検証
1.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問題とも言われるわけがない。でも念のため検証した。
2.WDIDLE3 ~当初WDから配布されたアプリ
これも多くの方々がWD80EAAZで実施され、不成功だったことが多数報告されている。1件の成功事例も目にしたことは無い。よく似たモデル名のWD80EAZZとは異なるのだ。検証は省略する。
不成功の事例:「WDブルーHDDのIntelliPark無効化ができぬ。。」
3.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 であるということは、NVMeとして正常に認識できなかったということであるが、WD80EAAZはSATAであることは明らかなので、このメッセージが出たということは、コマンドがデバイスに正しく伝わらなかったと思われる。
この件は引き続き調査するつもりだが、すぐには解決できそうにないので、NOP以外の方法にもチャレンジすることにする。
4.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コマンドがうまく行ったら、その方法を教えてください。
5.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で回せば自動実行はできる。
6.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年。
目標は人によって異なるだろうが、1日80回以内を目標値とすることにした。
HDDの消耗を抑える対策も必要
ネットで見ると、HDDの寿命は、3~4年とか、26000時間から35000時間と書かれているサイトが多い。ちなみにWDのBlueは2年保証、RedとPurpleは3年保証で、Goldは5年保証である。
PCに搭載していれば、夜寝る時に電源を切ってしまえばよいのでその間はHDDもお休みできる。NASだと何もアクセスが無くても時々なぜだか動いているので、これで使用時間が若干増えることになる。
利用者がアクセスしない時間帯のHDD稼働時間とロードアンロードサイクルカウントについてもまだよく分かっていない。
ロードアンロードサイクルカウントが与える負荷と連続稼働時間による負荷など、消耗のリスクを総合的に把握して考える必要がある。
起動時の自動実行の設定
手動で実行しても良いけれども、起動時に自動実行させる方法もある。
Synology DSMにログインして、「コントロールパネル」から「タスク スケジューラー」を起動する。
「作成」からプルダウンで「トリガーされたタスク」→「ユーザー指定のスクリプト」を選択する。項目には以下のように設定する。
タスク:任意の名称を設定
イベント:「ブートアップ」が起動時
ユーザー指定のスクリプト:/bin/bash /xxx/yyy/keepalive.sh &
設定を保存すれば、次に再起動したときに自動的にこのスクリプトが実行されるようになる。
SSHからのSMART情報の確認方法
bashから、”sudo smartctl -a /dev/sda” このように叩いても、HDDのベンダーや型名や容量などの一般情報は得られるのだが、肝心のSMARTデータのセクションに来ると、”not supported”となってしまう。
=== START OF READ SMART DATA SECTION ===
Current Drive Temperature: 0 C
Drive Trip Temperature: 0 C
Error Counter logging not supported
そこで次のようにpermissiveを付けてコマンドを叩くと全ての情報が得られた。
$ sudo smartctl -a -d sat -T permissive /dev/sda
smartctl 6.5 (build date Oct 7 2021) [armv7l-linux-3.10.108] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Blue (CMR)
Device Model: WDC WD80EAAZ-xxxxxxx
Serial Number: WD-xxxxxxxx
LU WWN Device Id: xxxxxxxxxx
Firmware Version: 01.01A01
User Capacity: 8,001,563,222,016 bytes [8.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5640 rpm
Form Factor: 3.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-3 T13/2161-D revision 5
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Mon May 5 11:14:56 2025 JST
SMART support is: Available – device has SMART capability.
SMART support is: Enabled
Warning! SMART Attribute Thresholds Structure error: invalid SMART checksum.
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 9524) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 770) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x0031) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always – 0
3 Spin_Up_Time 0x0027 188 187 021 Pre-fail Always – 7566
4 Start_Stop_Count 0x0032 099 099 000 Old_age Always – 1051
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always – 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always – 0
9 Power_On_Hours 0x0032 099 099 000 Old_age Always – 1324
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always – 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always – 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always – 980
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always – 0
193 Load_Cycle_Count 0x0032 196 196 000 Old_age Always – 13900
194 Temperature_Celsius 0x0022 122 117 000 Old_age Always – 30
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always – 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always – 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline – 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always – 0
200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline – 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 13 –
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
“Warning! SMART Attribute Thresholds Structure error: invalid SMART checksum.” というエラーが出てちょっと気になって調べてみたが、無害なファームのバグであり、smartctlの問題ではないようである。https://www.smartmontools.org/ticket/347
補足情報
touchの実行間隔について
touchの間隔を9秒にして7.2日間稼働させたところ、HDD1、HDD2それぞれ17回、18回のLord Cycle Countの増加であった。1日平均で2.3回~2.5回程度だ。増加はゼロではないけれども、気にするほどの増加量でもない。
9秒でtouchを設定している時にNASを何も使用していないでいても何秒か毎にHDDにアクセスする音がする。それは9秒よりも短くて7秒とか4秒とか不規則である。何らかのプロセスが動いているだろうが詳細は分からない。9秒より間隔を広くしても良さそうだ。10秒にしてみようと思う。
10秒間隔に設定したところ、Load Cycle Countの数値は58時間経過後、HDD1は32回増加、HDD2は35回の増加となった。1日平均ではそれぞれ、13.2回、14.4回。利用状況によっても変わるだろうが、私のNASではこのような結果になった。
Synology NASの省電力設定
Synology NASには省電力設定があり、一定期間利用が無い場合に内蔵ハードディスクと外部SATAディスクを休止状態にできる機能がある。「10分、15分、20分、30分、1時間、2時間、3時間、4時間、5時間」の中から選べる。
「コントロールパネル」の「ハードウェアと電源」から「HDDハイバネーション」で設定できる。この記事の中では、省電力機能は無効にしている。
こんにちは。様々な検証ありがとうございます。
go-ata-nopのATAコマンドをsg_raw形式にすると以下のようになると思いますがどうでしょうか。
sudo sg_raw /dev/sda 85 07 00 00 00 00 00 00 00 00 00 00 00 00 40 00
参考:https://github.com/woremacx/go-ata-nop/blob/0c8bdb7f7ce2e6810c4b18b349f0a605c0e56866/main.go#L83
コメントありがとうございます。
コードの中のLine#85にある、 (3 << 1) | 1 は計算すると 07 です。 sudo sg_raw /dev/sda 85 07 00 00 00 00 00 00 00 00 00 00 00 00 40 00 を実行すると、以下の結果が得られました。 SCSI Status: Check Condition Sense Information: Descriptor format, current; Sense key: Aborted Command Additional sense: Recorded entity not found Descriptor type: ATA Status Return: extend=1 error=0x10 count=0x0 lba=0x000000000000 device=0x0 status=0x51 今までの結果とは少し異なっていますが、全体としてはそのままコマンドは受け入れられなかったように見えます。 私が基本的な事を理解していない / 何か重要な情報が抜け落ちているのかもしれません。 以下はAIに調べてもらった解説を貼り付けます。 ■ SCSI Status: Check Condition ・デバイスが何らかのエラー条件を返したことを示します(SCSIコマンドの実行が期待通りでなかったことを意味します)。 ■ Sense key: Aborted Command ・コマンドが中断された(ハードウェアやファームウェアが受け付けなかった)ことを示します。 ・通常これはコマンドがサポートされていない、あるいは無効な形式である場合に出ます。 ■ Additional sense: Recorded entity not found ・ATA側の追加情報で、意味としては「該当する情報が存在しない」とされています。NOPの処理に失敗した可能性があります。 ■ ATA Status Return ・extend=1:48-bit LBAアクセスを使っていたことを示します。 ・error=0x10: これは ATA の error レジスタで「ID Not Found」または「Address Mark Not Found」のような意味です(コマンドが宛先を見つけられなかったなど)。 ・status=0x51: ATA ステータスレジスタ:0x51 = ERR (bit 0) + DRDY (bit 6) → エラーが発生しつつ、デバイス自体は Ready 状態。 ・device=0x0:デバイスヘッダ情報がゼロ。NOPには関係ないフィールド。