Ich habe einen 24/7 Always-on Debian Jessie-basierten Headless-Home-Server, der über eine große 1-TB-SSD für das Betriebssystem und alle meine häufig aufgerufenen Dateien verfügt. Dasselbe System verfügt über 4 größere Festplattenlaufwerke in einem SnapRAID-Array. Diese dienen hauptsächlich zum Archivieren von Blu-rays, auf die selten zugegriffen wird, und möchten, dass diese Laufwerke im Standby-Modus heruntergefahren bleiben, es sei denn, ich lese oder schreibe tatsächlich auf sie. Sie sind alle als ext4 formatiert und mit aktiviertem noatime und nodiratime gemountet.
Obwohl also kein Prozess oder Programm regelmäßig direkt auf diese Laufwerke zugreifen sollte, werden die Festplatten ständig aus dem Standby hochgefahren. Es scheint mit grafischen Programmen zusammenzuhängen, die einen GUI-Dateibrowser bereitstellen, sogar so etwas wie Chromium. Wenn ich diese Laufwerke nicht einmal durchsuche, denke ich, dass diese Prozesse durch einfaches Abrufen einer Liste verfügbarer Laufwerke die Festplatten hochfahren. Ähnlich wie blkid es tut. Das Problem ist, dass es schwierig ist, die Ursache dafür zu bestimmen, da keiner dieser Prozesse das Dateisystem auf diesen Laufwerken tatsächlich liest oder schreibt, sodass sich keine Dateien tatsächlich ändern oder berühren. Gibt es eine Art Cache, den ich füllen kann, oder einen Puffer, um zu verhindern, dass diese Programme die Festplatte hochfahren, indem ich einfach eine Liste der verfügbaren Festplatten erhalte? Das macht mich ehrlich gesagt wahnsinnig, da ich keinen zuverlässigen Weg finden kann, diese Festplatten herunterzufahren, obwohl es keinen direkten Zugriff auf das Dateisystem gibt.
AKTUALISIEREN :Dank Stephens Antwort konnte ich die Festplattenaktivität auf gvfs zurückverfolgen und udisks . Es ist eine echte Schande, dass diese Prozesse darauf bestehen, Festplatten im Standby-Modus aufzuwecken, wenn nicht wirklich auf sie zugegriffen wird, um echte I/O mit dem Dateisystem auszuführen. Bisher habe ich sie nur deinstalliert, weil ich wusste, dass dadurch einige Funktionen von PCManFM und dergleichen entfernt werden.
Akzeptierte Antwort:
Sie können blktrace verwenden (verfügbar in Debian), um alle Aktivitäten zu einem bestimmten Gerät zu verfolgen; zum Beispiel
sudo blktrace -d /dev/sda -o - | blkparse -i -
oder einfach nur
sudo btrace /dev/sda
zeigt alle Aktivitäten auf /dev/sda . Die Ausgabe sieht so aus:
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
Die fünfte Spalte ist die Prozesskennung und die letzte gibt den Prozessnamen an, falls vorhanden.
Sie können auch Traces für spätere Analysen speichern; blktrace enthält eine Reihe von Analysetools wie das oben erwähnte blkparse und btt . blktrace ist ein Tool auf sehr niedriger Ebene, daher ist es möglicherweise nicht so einfach herauszufinden, was die Aktivität überhaupt verursacht hat, aber mit Hilfe der mitgelieferten Dokumentation (siehe /usr/share/doc/blktrace wenn Sie das Debian-Paket installiert haben) und den blktrace Papier sollte es möglich sein, herauszufinden, was die Spin-ups verursacht.