Dexter

Wenn ich htop beobachte in den moment wenn traffic ist steht da: lsof -Owl /mnt/disk1 /mntdisk2 /mnt/disk4 Das übersteigt aber meinen Horizont ob das das problem sein könnte.

Da ich das gleiche Problem habe kann ich bestätigen das auch bei mir die Platten mit hilfe der Tachoanzeige bei genau 60 Sekunden wieder angehen.

Danke für den Tipp, werte habe ich hochgesetzt und dann lief auch das Plugin, Leider brachte das keine weitere erkenntnis. Wenn selbst daten kopiert habe konnte ich das in der Übersicht sehen aber als ich nach ein paar Stunden nach geschaut habe, waren da keine einträge drin die das aufwecken der HDDs erklären könnten. Jetzt habe ich ebend gesehen das noch jemand genau das gleiche Problem nach den Cache wechsel bekommen hat. Die Idee mit einen anderen Stick und der Test Lizens scheint erstmal die einzige möglichkeit zu sein die Sache weiter einzugrenzen.

Ok, habe ich gemacht. In Disk Activity und Share Activity Tab wird mir garnichts angezeigt auch wenn ich Dateien Lese und Schreibe. Sep 14 12:33:51 Tower file.activity: File Activity inotify starting Sep 14 12:33:51 Tower inotifywait[28094]: Setting up watches. Beware: since -r was given, this may take a while! Sep 14 12:34:17 Tower inotifywait[28094]: Failed to watch /mnt/disk4; upper limit on inotify watches reached! Sep 14 12:34:17 Tower inotifywait[28094]: Please increase the amount of inotify watches allowed per user via `/proc/sys/fs/inotify/max_user_watches'. Sep 14 12:34:17 Tower file.activity: File Activity inotify exiting

Es hatte mal Funktioniert das die Platten runtegefahren sind. Ich habe vor kurzem den Cache ausgewechselt von einer 500SSD zu einer 1TB NVME da ist mir das dann aufgefallen. Würde das dann nicht auch die Parity betreffen, die geht ins Spin Down. Kann ich heute abend aber mal im Bios nach schauen. Deinstallation von File Aktivity hatte nichts gebracht. Nein, die sind alle an SATA angeschlossen. Die NVME über PCI Steckplatz. Was ich nicht nachvollziehen kann ist das sich die Read und Write werte seit Stunden nicht ändern die Platten aber nicht herrunter fahren. Mache ich das Spin Down manuell dann dauert das ca 20 Sekunden und sie fahren wieder hoch. Da sind doch dann keinerlei Daten anfragen wobei auch noch Docker und VM Deaktiviert sind. Irgendwie ganz komisch. Vielleicht mal Unraid neu aufsetzen?

Ja aber... es liegt alles komplett im Cache und selbst wenn ich Docker und VM deaktiviere bekomme ich die Platte nicht ins Spin Down. @alturismo Ok, ich werde jetzt mal File Aktivity Deinstallieren und mal schauen was passiert.

Sata Platten. Parity: ST8000VN0022-2EL112 HDD1: WDC_WD60EFRX-68L0BN1 HDD2: WDC_WD60EFAX-68SHWN0 HDD4: WDC_WD60EFRX-68L0BN1 Die Werte der Writes und Reads sind seit Stunden unverändert. Die Parität (sde) hat es geschafft und ist schon länger im Spin Down. Sep 13 07:25:12 Tower emhttpd: spinning down /dev/sdd Sep 13 07:26:05 Tower emhttpd: read SMART /dev/sdd Sep 13 08:16:52 Tower emhttpd: spinning down /dev/sdb Sep 13 08:17:09 Tower emhttpd: read SMART /dev/sdb Sep 13 08:21:54 Tower emhttpd: spinning down /dev/sde Sep 13 08:21:54 Tower emhttpd: spinning down /dev/sdc Sep 13 08:22:09 Tower emhttpd: read SMART /dev/sdc Sep 13 08:26:02 Tower emhttpd: spinning down /dev/sdd Sep 13 08:27:05 Tower emhttpd: read SMART /dev/sdd Sep 13 09:17:02 Tower emhttpd: spinning down /dev/sdb Sep 13 09:18:11 Tower emhttpd: read SMART /dev/sdb Sep 13 09:22:03 Tower emhttpd: spinning down /dev/sdc Sep 13 09:23:11 Tower emhttpd: read SMART /dev/sdc Sep 13 09:27:03 Tower emhttpd: spinning down /dev/sdd Sep 13 09:28:05 Tower emhttpd: read SMART /dev/sdd Sep 13 10:18:03 Tower emhttpd: spinning down /dev/sdb Sep 13 10:19:11 Tower emhttpd: read SMART /dev/sdb Sep 13 10:23:04 Tower emhttpd: spinning down /dev/sdc Sep 13 10:24:11 Tower emhttpd: read SMART /dev/sdc Sep 13 10:28:03 Tower emhttpd: spinning down /dev/sdd Sep 13 10:29:05 Tower emhttpd: read SMART /dev/sdd Sep 13 11:19:02 Tower emhttpd: spinning down /dev/sdb Sep 13 11:20:11 Tower emhttpd: read SMART /dev/sdb Sep 13 11:24:03 Tower emhttpd: spinning down /dev/sdc Sep 13 11:25:11 Tower emhttpd: read SMART /dev/sdc Sep 13 11:29:03 Tower emhttpd: spinning down /dev/sdd Sep 13 11:30:05 Tower emhttpd: read SMART /dev/sdd

Motioneye ist nicht mehr installiert. Den Share kann ich auch löschen. Das ergibt keine ausgabe. root@Tower:/mnt/user# lsof -a /mnt/disk1 root@Tower:/mnt/user# lsof -a /mnt/disk2 root@Tower:/mnt/user# lsof -a /mnt/disk4 root@Tower:/mnt/user#

Hier einmal die ausgabe.

Hallo zusammen, ich bin mir bewusst das das Problem schon oft behandelt und gelöst wurde aber das alles klappt bei mir irgendwie nicht. VM sowie Docker sind deaktiviert. Docker-Dateien, appdata, vm´s, system, domains sind alle Cache only. Trotzdem werden die Festplatten kurz nachdem Spin Down wieder hochgefahren. Sep 13 02:10:34 Tower emhttpd: spinning down /dev/sdc Sep 13 02:11:12 Tower emhttpd: read SMART /dev/sdc Sep 13 03:09:50 Tower emhttpd: spinning down /dev/sdd Sep 13 03:10:05 Tower emhttpd: read SMART /dev/sdd Sep 13 03:11:46 Tower emhttpd: spinning down /dev/sde Sep 13 04:10:03 Tower emhttpd: spinning down /dev/sdd Sep 13 04:11:05 Tower emhttpd: read SMART /dev/sdd Sep 13 05:20:23 Tower emhttpd: read SMART /dev/sde Habe schon diverse Plugins Deinstalliert und auch versucht mit Hilfe des Plugin Open Files rückschlüsse zu ziehen aber alles erfolglos. Ich weiß nicht wo ich jetzt noch ansetzten kann. Ich bin über jede Hilfe dankbar. Hier einmal die Shares und Diagnostics tower-diagnostics-20240913-0520.zip