夜間のライブラリスキャンでハードドライブが何度も起動する：回数を減らす方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Overnight Library Scans Keep Waking Hard Drives: How to Reduce Them

メディアにアクセスする正確なスケジュールタスクを特定し、その実行頻度、対象範囲、またはファイル単位の処理を制限することで、夜間にドライブがスリープから復帰する回数を減らせます。

データベースとキャッシュをSSDに置いていても、メディアサーバーはスリープ中のHDDを復帰させることがあります。スケジュールされたライブラリスキャンがディレクトリを走査し、ファイルを調査し、アートワークを更新し、プレビューを生成し、パスを検証し、あるいは安定した状態にならない項目を処理する可能性があるためです。まず、最初のディスクアクセスを1つのタスクと1つのログエントリに関連付けます。トリガーを確認する前にスピンダウンタイマーを変更しても、根本的な読み取りを減らさず、パターンを見えにくくするだけです。

どのスケジュールタスクがドライブを復帰させるか確認する

ディスクのテレメトリ、システムログ、または電力モニタリングから正確な復帰時刻を記録し、メディアサーバーのスケジュールタスク履歴と比較します。原因と思われるタスクを1つだけ一晩無効にして、結果をそのタスクに帰属できるようにします。

あるJellyfinの報告では、スケジュールされたライブラリスキャンがライブラリ全体を1日に2回繰り返し処理し、メディアの調査に何時間も費やしていました。重要な手がかりは、単発の再生リクエストではなく、同じ全体スキャンが繰り返されていたことでした。

ライブラリスキャンの開始前にドライブが復帰する場合は、チャプター画像の抽出、トリックプレイ生成、イントロ解析、メタデータ更新、バックアップ、SMARTテスト、ファイルシステムのスクラブ、ダウンロード整理など、別のタスクを調べてください。最初のアクセス記録にプロセスまたはコンテナが現れるまでは、メディアサーバーを原因と決めつけないでください。

ライブラリ全体のスキャンとリアルタイム監視を分けて考える

ライブラリで、定期的な全体スキャンとファイルシステム監視の両方が有効になっているか確認します。対応しているローカルファイルシステムでは、リアルタイム監視により通常の追加をすばやく取り込める一方、スケジュールされた全体スキャンは低頻度の安全策として役立ちます。

Jellyfinでは、スケジュールスキャンとリアルタイム監視は以前から別の仕組みとして扱われています。プロジェクトのIssueでは、リアルタイム監視で新しいメディアを検出できる一方、スケジュールタスクが間隔ベースの検出を提供すると説明されています。

信頼性の高いローカルストレージでは、新しく追加したファイルを1つ使ってリアルタイム監視をテストし、そのファイルが正しく表示されることを確認してから全体スキャンの頻度を下げます。NFS、SMB、rclone、mergerfsなどのファイルシステムや、一部のコンテナマウントパスではイベント通知が不完全な場合があるため、ストレージポリシーに合った時刻に定期スキャンを残してください。

ディレクトリ名だけでなくメディアの内容を読み取るタスクを見つける

スキャナーログで、メディアの調査、チェックサムの読み取り、チャプター抽出、字幕解析、トリックプレイ生成、音量解析、メタデータの繰り返し更新を確認します。ディレクトリの列挙だけなら短時間の復帰で済むことがありますが、すべてのファイルの一部を読み取る処理では、アレイ全体が何時間も稼働し続ける可能性があります。

前述の繰り返しスキャンの事例では、調査中に各メディアファイルから大量のデータが読み取られており、処理がファイル名の確認だけではなかったことが分かります。別のIssueでは、同じ項目がスキャンのたびに再処理されていたことが示されており、安定した状態に到達していませんでした。

毎回変化する最初の項目を修正します。利用できないパス、権限エラー、不正なサイドカー、安定しないタイムスタンプ、重複したライブラリルート、または繰り返し削除・再作成されるメタデータレコードなどです。各スキャンが同じコンテンツを新規項目として扱い続けるなら、スケジュールを短くしても効果はありません。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

メタデータをSSDに置いても、すべての復帰が止まるとは限らない

プラットフォームが対応している場合は、アプリケーションデータベース、キャッシュ、ポスター、使用中のメタデータをSSDに置きます。これにより、ブラウジング中の小さなランダム読み取りを減らし、容量ディスク上での日常的なデータベースメンテナンスを避けられます。

ストレージを分離しても完全な保証にはなりません。Jellyfinの回帰報告では、キャッシュとメタデータをNVMeに置いていてもライブラリの詳細表示中にHDDが復帰しており、特定の処理ではサーバーがソースメディアにアクセスする可能性が示されています。

アプリデータを移動した後は、ブラウジングやスキャン中にどのソースパスが開かれているかを確認します。可能であればポスター、プレビュー、データベースをメディアディスクから分離します。ただし、残っているソースファイルへのアクセスは、SSDへの移動が失敗した証拠ではなく、別の動作として切り分けて調査してください。

頻度、対象範囲、重複する処理を減らす

全体スキャンはライブラリに必要な頻度でのみ実行し、バックアップ、スクラブ、プレビュー生成、メディアの取り込みと同じ時間に実行しないようにします。プラットフォームが対応している場合は、対象を絞った更新で個別のライブラリやフォルダーをスキャンします。

メタデータを実際に再構築する必要がない限り、通常のスキャンで広範囲のメタデータ置換を無効にします。通常の増分スキャンで、変更されていないメディアのチャプター画像、トリックプレイファイル、ポスター、エピソード識別を何度も再生成するべきではありません。

取り込みを先に行い、取り込み時間帯の後に対象を絞ったライブラリ更新を実行し、大容量の派生データ生成は別の日、または必要なときだけ実行するよう、スケジュールを分散させます。これにより、夜間に短い復帰が何度も発生するのではなく、予測可能な1つの稼働時間にまとめられます。

メディアサービスの起動前にマウントの利用可能性を確認する

ネットワークマウントやプールマウントが見つからないと、想定されたパスに空のローカルディレクトリが表示されることがあります。メディアサーバーがその代替パスをスキャンして項目を削除し、実際の共有が戻ったときにすべてを再スキャンする可能性があります。

ドライブやマウントの切断によりメディアライブラリが消失し、高コストな再構築が必要になる場合があります。JellyfinのIssueでは、マウント切断後にライブラリが失われた事例が説明されており、これは起動依存関係によって防ぐべき障害モードです。

必要なマウントが有効かつ内容を利用できる状態になってからコンテナやサービスが起動するよう設定します。既知のマーカーや想定されるファイルシステムタイプを確認するマウント存在チェックを追加し、ストレージパスが利用できない場合はスキャンを停止します。空のディレクトリを有効なライブラリとして扱わないことが重要です。