コミュニティソリューション

ZimaOSのHDDスタンバイが機能しない:ディスクを起動状態に保つ原因を特定し、1.3.2および1.6.0の修正内容を理解する

A January 2025 ZimaCube thread where six RAID5 HDDs never entered a configured 20-minute standby state even after Docker apps were stopped. IceWhale acknowledged the issue, documented upcoming 1.3.2 storage-health/cache changes, and provided commands to identify processes accessing the disks. ZimaOS 1.6.0 later fixed another wake source caused by smartd.

この情報源は、単なる「ドライブがまったくスリープしない」という一般的な不満よりも有力です。IceWhaleが製品の修正計画と診断方法の両方を示しているためです。Dockerアプリケーションを停止した後も6台のRAID5 HDDが動作し続けたため、調査はZimaOSのストレージ/ヘルスサービスと、カーネルレベルでの動作の可能性へと移りました。

その後、ZimaOS 1.3.2では不要なディスククエリが削減され、スタンバイ動作が改善されました。さらに後のZimaOS 1.6.0では、smartdがスリープ中のディスクを断続的に起こしていた別の具体的な問題が修正されました。これらのリリースによって既知のウェイク要因は解消されますが、現在もディスクが起動したままの場合は、別のアプリ、バックアップ、インデクサー、ファイルシステムタスク、USBブリッジ、またはカーネルサービスがアクセスしている可能性があります。

ZimaOSのシステムモニターに、スタンバイトラブルシューティング中の複数のHDDデバイスで継続的なI/Oカウンターが表示されている
情報源のユーザーは、アプリケーションの負荷を下げた後も複数のHDDでアクティビティが発生していることを確認しました。

IceWhaleはZimaOS 1.3.2でストレージのポーリングを変更

orca-zhangは、1.3.2で予定している3つの具体的な最適化について説明しました。

  • ヘルスチェックのロジックを簡素化する。
  • ディスクの変更が検出された場合にのみ、ディスクデータのキャッシュを更新する。
  • すでにスタンバイ状態にあるディスクから、温度や電源投入時間などの情報を取得しようとしない。

この理由は重要です。一部のHDDやコントローラーは、キャッシュからこれらのクエリに応答できないため、ヘルスデータを要求すると物理ディスクが起動してしまいます。

現在の1.3.2のリリースノートでは、この対応を不要な読み書きアクティビティの削減と、ディスクスタンバイの改善としてまとめています。

IceWhaleはプロセスによるアクセスを確認するクエリを提供

公式の情報源で示された回答では、現在ファイルシステムまたはデバイスを開いているプロセスを特定する方法が提案されています。

for pid in $(fuser -m <device_path> 2>/dev/null); do
  ps -p $pid -o comm=
done | uniq

<device_path>を実際のディスクまたはマウント済みストレージのパスに置き換えてください。これは診断用であり、破壊的な操作ではありません。

IceWhaleはストレージ/ファイルサービスを一時停止する方法も提案

トラブルシューティングでは、次のサービスを停止した後にスタンバイをテストする方法が提案されています。

systemctl stop zimaos-local-storage
systemctl stop icewhale-files

IceWhaleは、これらのサービスを停止している間は、設定とファイルの一部の機能が動作しなくなると警告しています。これは管理された診断としてのみ実行し、その後サービスを再起動するか、再起動してください。

ZimaOS 1.6.0で別の既知のウェイク要因を修正

後の公式1.6.0変更履歴では、別の修正も追加されました。smartdサービスが断続的にディスクを起こすため、ディスクが通常のスリープ状態に移行できないことがありました。

公式のsmartdスタンバイ修正を参照してください。

AppDataをNVMeに移動しても、HDDがアイドル状態になるとは限らない

情報源のユーザーは、DockerのデータベースをすでにNVMeへ移行していました。それでもHDDは、メディアスキャン、バックアップ、サムネイル生成、SMBクライアント、SMARTチェック、RAID/パリティタスク、ファイルのインデックス作成、またはパスを開いたままにしているプロセスによってアクセスされる可能性があります。

「すべてのアプリがNVMe上にある」ことからアレイのI/Oがゼロだと判断せず、実際のアクセスの証拠を確認してください。

RAID5自体がバックグラウンドアクティビティを発生させる可能性がある

パリティチェック、再構築、スクラブ、ファイルシステムのメタデータ処理、監視などによって、すべてのメンバーディスクに正当なアクセスが発生することがあります。スタンバイを診断する前に、RAIDが長時間のメンテナンス処理を実行していないことを確認してください。

古いサービス回避策を適用する前に、現在のZimaOSでテストする

現在のZimaOSは1.7.1であり、2025年1月のこの報告以降、ストレージ管理に関する長年の変更が加えられています。まず現行リリースで問題を再現し、次にウェイク要因を特定してください。スピンダウンを強制するためだけに、ヘルスサービスやストレージサービスを恒久的に無効にしないでください。

ディスクスタンバイに関するFAQ

IceWhaleは情報源でスタンバイの問題を認めましたか?

はい。スタッフは調査中であると述べ、1.3.2での最適化について説明しました。

ドライブの温度やヘルス状態を確認すると、一部のディスクが起動することはありますか?

はい。IceWhaleは、キャッシュされた情報を持たない一部のドライブでは、クエリによって起動する可能性があると明確に説明しています。

smartdが後に別のウェイク要因として特定されましたか?

はい。ZimaOS 1.6.0では、通常のスリープを妨げていたsmartdの断続的なウェイクアップが明確に修正されました。