ユーザーのアクセスがないのに、HDDがスピンダウンしてすぐに復帰するのはなぜですか？
HDDは通常、スピンダウン直後にすぐ復帰します。これは、バックグラウンドプロセス、監視ツール、クライアント、ジャーナル、またはスケジュールタスクが新たなコマンドを発行するためです。
「ユーザーによるアクセスがない」ことは、オペレーティングシステムのレベルでディスクがアイドル状態であることを意味しません。SMARTのポーリング、メディアや写真のインデクサー、クラウド同期、バックアップ検出、ファイルシステムのメタデータ、ログ、スワップ、コンテナ、ファイルブラウザー、定期タイマーなどが、スタンバイに入って数秒後のデバイスにアクセスすることがあります。まずは本当にスタンバイへ移行したことを確認し、復帰そのものを引き起こす監視コマンドを使わずに、ディスクを復帰させた最初のプロセスまたはコマンドを記録することが重要です。
ドライブが実際にスタンバイへ移行したことを確認する
スピンダウン直前、コマンドまたはアイドルタイマーの実行後、そして音が聞こえて復帰した後に、ドライブの電源モードを記録します。また、デバイスが内蔵SATA、USB-SATA、SASのいずれなのか、またはエンクロージャー経由なのかも記録してください。
hdparmの電源モード確認では、アクティブまたはアイドル、スタンバイ、スリープの状態を区別できます。これにより、プラッターが回転したままのヘッドアンロードや低電力状態と、実際のスピンダウンを切り分けられます。
テスト対象のインターフェースでデバイスをアクティブ状態に強制移行しないことが確認できている電源状態クエリだけを使用してください。一部のUSBブリッジでは、直接接続したSATAとはATA電源コマンドの変換方法や拒否のされ方が異なります。
スピンダウン後の最初のファイルアクセスを追跡する
予想されるスタンバイ時刻の前に、短時間のファイルアクセス追跡を開始し、ドライブが復帰した直後に停止します。結果は、対象のマウントポイント、デバイス、またはデータセットに絞り込んでください。
Ubuntuのfatraceユーティリティはファイルアクセスイベントを報告します。これにより、復帰時刻にディスクへアクセスしたサムネイル生成ツール、インデクサー、データベース、シェル、バックアップツールなどを特定できます。
負荷の高い追跡を何日も有効にしたままにしないでください。再現可能な復帰イベントの前後に時間枠を限定し、疑わしいサービスだけを1サイクル停止して、そのプロセスを検証します。
SMARTのポーリングがディスクを復帰させていないか確認する
smartdの設定、NASのディスク健全性ポーリング間隔、定期的なショートテストとロングテスト、温度チェック、サードパーティ製監視ダッシュボードを確認します。それぞれの実行時刻と復帰イベントを比較してください。
Debianのsmartd設定リファレンスには、電源モードの確認を設定してスタンバイ中のデバイスをスキップしない限り、SMARTコマンドは通常ディスクのプラッターをスピンアップさせると記載されています。
スリープ時間を延ばすためだけに、健全性監視を恒久的に無効にしないでください。プラットフォームとドライブが対応している場合は、チェックを意図した時間帯に移動するか、スタンバイを認識するポーリングを設定します。
同期、インデックス作成、パッケージ、ネットワーククライアントを確認する
写真やメディアのインデックス作成、クラウド同期、ウイルス対策、検索、サムネイル生成、バックアップエージェント、監視アプリ、コンテナ、接続中のSMBまたはNFSクライアントを一覧にします。スリープ中のストレージプールを監視しているサービスがないか確認してください。
Synologyの休止トラブルシューティングガイドでは、休止を中断するパッケージとサービスとして、同期、スケジュールされたディスクテスト、ネットワークアクティビティ、ディスクI/Oを引き起こすメモリ圧迫などを挙げています。
誰もファイルを開いていなくても、サービスがディスクを復帰させることがあります。サービスを一度に1つずつテストし、必要なバックアップ、監視、セキュリティ機能は維持してください。
タイマー、cronジョブ、起動後のキャッチアップを確認する
systemdタイマー、cronジョブ、NASのスケジュール、バックアップ検出、スクラブタスク、データベースのメンテナンス、ログローテーション、一時ファイルのクリーンアップ、実行を逃した場合に追いつくよう設定されたジョブを一覧にします。
ArchWikiでは、systemdタイマーがスケジュールに従ってサービスを起動する仕組みを説明しています。これにより、バックグラウンドジョブごとに間隔が異なる場合、ドライブが一見ランダムに復帰することがあります。
タイマーのサービスログを、最初に追跡されたディスクアクセスと照合します。すべてのジョブを同じ分に移動すると復帰時の負荷が集中する一方、間隔を広げすぎると実質的にスタンバイできなくなる可能性があります。
NASのスタンバイテストを使用し、ドライブを1台ずつ検証する
NASに内蔵のスタンバイ診断機能がある場合は、通常のアプリケーションを一時停止し、1つのエンクロージャーまたはドライブグループを選択して実行します。レポートを保存し、プロセスの追跡結果と比較してください。
QNAPでは、エンクロージャー単位のHDDスタンバイテストを説明しています。これは、すべてのNASディスクを1つの電源ドメインとして扱うのではなく、影響を受けたストレージグループを分離して復帰を調査すべき理由を示しています。
すべてのディスクが同時に復帰する場合は、共有プールのメタデータ、システムデータセット、RAIDの動作、アレイ上に保存されたサービスを確認します。1台だけが復帰する場合は、そのドライブのマウント、監視、ワークロードを個別に調べてください。
常にスピンダウンを繰り返すのではなく、安定したアイドル動作を選ぶ
復帰の原因を特定したら、実行時間を変更する、アプリデータやログをSSDへ移動する、スタンバイ対応の監視を使用する、またはサービスの稼働時間中は使用中のプールを回転させたままにするかを判断します。
ZimaSpaceの24時間365日のNAS消費電力に関する記事では、省エネルギーと、信頼性の高いバックアップ、アプリ、インデックス作成、リモートアクセスを維持することの隣接するトレードオフについて説明しています。
意図したアイドル時間のあいだドライブがスタンバイを維持するか、記録されたタスクの実行時だけ復帰するなら、問題は解決しています。ワークロードが数分おきに本当にディスクを必要としている場合、強制的にスリープさせ続けても解決にはなりません。
よくある質問
SMARTデータを確認すると、スリープ中のHDDが復帰することはありますか？
はい。多くのSMARTコマンドは、監視ツールが先に電源モードを確認し、すでにスタンバイ中のデバイスをスキップしない限り、ディスクをスピンアップさせます。
ファイルを開かなくても、ファイルブラウザーがNASディスクを復帰させることはありますか？
はい。ディレクトリの列挙、プレビュー、サムネイル、空き容量の確認、メタデータの読み取り、マウント済み共有の再接続などは、すべてストレージアクセスを発生させる可能性があります。
ドライブを稼働させたままにするより、頻繁にスピンアップとスピンダウンを繰り返す方が常に悪いですか？
一律に適用できるしきい値はありません。実際の目標は、ワークロードに合った安定した動作です。長いアイドル時間があるならスタンバイにする意味がありますが、数分おきに復帰する場合は電力上のメリットがほとんどなく、遅延が増えることもあります。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
