私は24時間年中無休のDebianJessieベースのヘッドレスホームサーバーを持っており、OSと頻繁にアクセスするすべてのファイル用に1TBSSDを搭載しています。この同じシステムには、SnapRAIDアレイに4台の大型ハードディスクドライブがあります。これらは主に、アクセス頻度の低いBlu-rayをアーカイブするためのものであり、実際に読み取りまたは書き込みを行わない限り、これらのドライブをスタンバイ状態でスピンダウンしたままにしておきます。 これらはすべてext4としてフォーマットされ、noatimeとnodiratimeが有効になっている状態でマウントされます。
したがって、プロセスやプログラムがこれらのドライブに直接アクセスすることはありませんが、ハードドライブは常にスタンバイ状態から起動します。 これは、Chromiumのようなものでさえ、GUIファイルブラウザを提供するグラフィカルプログラムに関連しているようです。これらのドライブを参照していなくても、使用可能なドライブのリストを取得するだけでこれらのプロセスがハードディスクを起動すると思います。 blkidと同じように。 問題は、これらのプロセスのいずれも実際にこれらのドライブのファイルシステムを読み書きしておらず、ファイルが実際に変更または変更されていないため、これの根本的な原因を特定するのが難しいことです。使用可能なディスクのリストを取得するだけで、これらのプログラムがハードドライブを起動しないようにするために、データを入力できるキャッシュやバッファはありますか？ファイルシステムに直接アクセスできない場合でも、これらのディスクを確実にスピンダウンしておく方法が見つからないため、これは正直なところ私を狂わせています。
更新 ：Stephenの回答のおかげで、ディスクアクティビティを gvfsまで追跡できました。 およびudisks 。これらのプロセスが、ファイルシステムで実際のI / Oを実行するために実際にアクセスされていないときに、スタンバイ状態でディスクをウェイクアップすることを要求するのは本当に残念です。これまでのところ、PCManFMなどから一部の機能が削除されることを知って、それらをアンインストールしました。
承認された回答：
blktraceを使用できます （Debianで利用可能）特定のデバイスへのすべてのアクティビティを追跡します。たとえば
sudo blktrace -d /dev/sda -o - | blkparse -i -
または単に
sudo btrace /dev/sda
/ dev / sdaのすべてのアクティビティが表示されます 。出力は次のようになります
8,0 3 51 135.424002054 16857 D WM 167775248 + 8 [kworker/u16:0]
8,0 3 52 135.424011323 16857 I WM 209718336 + 8 [kworker/u16:0]
8,0 3 0 135.424011659 0 m N cfq496A / insert_request
5番目の列はプロセス識別子であり、最後の列はプロセス名がある場合はそれを示します。
後で分析するためにトレースを保存することもできます。 blktrace 前述のblkparseなどの多くの分析ツールが含まれています およびbtt 。 blktrace は非常に低レベルのツールであるため、そもそも何がアクティビティを引き起こしたのかを理解するのはそれほど簡単ではないかもしれませんが、含まれているドキュメントの助けを借りて（ / usr / share / doc / blktrace > Debianパッケージをインストールした場合）および blktrace 紙は、スピンアップの原因を突き止めることができるはずです。