どのプロセスがディスクに定期的に書き込みを行っているかを見つける方法は？

どのプロセスが常にディスクに書き込みを行っているかを見つけるにはどうすればよいですか？

ワークステーションが静かに近いのが好きで、静かなファンなどで新しいシステム（P8B75-M + Core i5 3450-最大TDPが低いため 's'）を構築し、Debian Wheezy 64ビットをインストールしただけですその上。

そして、何かが私の神経になっています：ハードディスクが何かを書いているか、何かを探しているかのようなパターンを聞くことができます（カチカチ...カチカチ...カチカチ... trrrrrrすすぎ、1秒ごとに繰り返します）。

過去に（多くの場合、何年も前に）同様の問題があり、CUPSログか何かであることが判明し、その（重要ではない）ログを（実際の）RAMディスクにリダイレクトしました。

しかし、ここではわかりません。

私は次を試しました：

ls -lR /var/log > /tmp/a.tmp && sleep 5 && ls -lR /var/log > /tmp/b.tmp && diff /tmp/?.tmp

しかし、何も変わっていません。

奇妙なことに、LVM復号化パスフレーズの入力を求めるプロンプトが表示されたときに、パターンも聞こえます。

インストールしたばかりのカーネル/システムに何かあるのでしょうか、それともハードディスクに欠陥がありますか？

hdparm -tT /dev/sda 正しいHD速度（130 GB / sキャッシュなし、sata 6GB）を報告し、大きなソース（Emacs）から問題なくインストールしてコンパイルしたので、システムが悪いとは思わない。

（HDはSeagate Barracude 500GBです）

どのようなプログラムiotopが表示されているかを調べようとしましたか？現在ディスクに書き込んでいるプロセスの種類が正確にわかります。

出力例：

Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
    6 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
    7 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/0]
    8 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/1]
 1033 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [flush-8:0]
   10 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/1]

経由echo 1 > /proc/sys/vm/block_dumpでIOデバッグを有効にしてから、/ var / log / syslogのデバッグメッセージを監視できます。これには、iotop現在のアクティビティのみを表示するのに対し、過去のアクティビティで何らかのタイプのログファイルを取得できるという利点があります。

ディスクのノイズは、ディスクのスピンダウンの問題ではなく、書き込みを引き起こすプロセスに起因すると仮定すると、監査サブシステムを使用できます（auditdパッケージをインストールします）。sync通話とその友人を監視します。

auditctl -S sync -S fsync -S fdatasync -a exit,always

のログをご覧ください/var/log/audit/audit.log。監査ログ自体がフラッシュされる場合は、これを行わないように注意してください！オプションがに設定され/etc/auditd.confていることを確認してください。flushnone

ファイルが頻繁にフラッシュされる場合、考えられる原因はシステムログです。たとえば、失敗した着信接続試行を記録し、誰かがマシンを調査している場合、多くのエントリが生成されます。これにより、ディスクから機関銃スタイルのノイズが発生する可能性があります。基本ログデーモンsysklogdを使用し/etc/syslog.confて、ログファイル名の前にが付いていない場合は-、書き込みのたびにそのログがディスクにフラッシュされます。

ドライブが自動的にスピンダウンする可能性がありますが、最近では多くの消費者グレードのドライブがそれを行っています。残念ながら、負荷の軽いシステムでも、特にhddtempなどを実行してドライブの温度を監視している場合、ほとんどのドライブは常にスピンダウンしてから再びスピンアップします（ほとんどのドライブではSMART温度の値を問い合わせることができませんドライブを回転させずに-クレチナス！）。

これは煩わしいだけでなく、多くのドライブのパークサイクルの数が限られているため、ドライブの消耗が早くなる可能性があります。たとえば、問題の説明については、https：//bugs.launchpad.net/ubuntu/+source/hdparm/+bug/952556を参照してください。

次のビットのシェルコードを使用して、すべてのドライブでアイドルスピンダウンを無効にします。/etc/rc.bootスクリプト、または/etc/rc.localなどに配置できます。

/ dev / sdのディスクの場合 ; 行う
  / sbin / hdparm -q -S 0 "$ disk"
やった

私はちょうどスマートが外付けUSBディスクを私のラズベリーパイで何度も起動させる原因であることがわかりました。SMARTは一般的に良いことですが、再度無効にすることにしました。それ以降、不要なディスクアクティビティが停止したようです。

これについて少し説明することができます。ほとんどの場合、それを絞り込む必要があります。

find / -mount -newer /proc -print

/ファイルシステムの物理デバイスでの起動後に変更されたファイルを提供します。ファイルを知ることは、作家を識別するのに役立つでしょう。

正確なディスクに絞り込む必要がある場合は、次を使用します。

実行lsblkしてデバイス番号を調べます。以下の場合は9:126

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda           8:0    0   7.3T  0 disk  
└─md126       9:126  0  13.8T  0 raid0 /mnt/InternalPhase
sdb           8:16   0   7.3T  0 disk  
└─md126       9:126  0  13.8T  0 raid0 /mnt/InternalPhase
sdc           8:32   0   7.3T  0 disk  
└─sdc1        8:33   0   7.3T  0 part  /mnt/InternalFBE

上記のディスク番号と比較しlsof | grep '9,126'て、:置換で実行し,ます。私の場合、これは次のように表示されます。

bash      389162            root  cwd       DIR              9,126      4096  449183796 /mnt/InternalPhase/0000000001/CHANNEL01/LIVE/PHASE/DATA/2018/10/04

次を389162使用してこのプロセスを強制終了するPID ：

kill -9 389162

問題は、システムがデフォルトで5秒ごとにディスクバッファからディスクにデータをフラッシュする必要があることです。したがって、ディスクがスピンダウンした場合、フラッシュが発生する必要があるときに再びスピンアップする以外のオプションはほとんどありません。したがって、スピンダウンまたはディスク電源管理機能を完全に無効にすること以外は、問題を実際に回避することはできませんhdparm -B 255 /dev/hdax。これはおそらく、常に再起動するだけではなく、頻繁に再起動することでより大きなダメージを与える可能性があるため、おそらくより良いオプションです。