September 13, 20241 yr 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
September 13, 20241 yr 13 minutes ago, Dexter said: Ich weiß nicht wo ich jetzt noch ansetzten kann. gib mal im unraid terminal folgendes ein (ja, mit der "0" am Ende) root@AlsServerII:~# ls -la /mnt/user0/ total 0 drwxrwxrwx 1 nobody users 19 Dec 7 2023 ./ drwxr-xr-x 13 root root 260 Sep 11 03:54 ../ drwxrwxrwx 1 nobody users 113 Jan 12 2024 Media/ root@AlsServerII:~#
September 13, 20241 yr 31 minutes ago, Dexter said: Hier einmal die ausgabe. ok, die 2 "üblichen" Verdächtigen hast du nicht, appdata und system ... motioneye ... ist das aktiv ? schreibt ja gerne video files der Kamera/s ansonsten sind da jede Menge Shares ... wird nicht einfach. probier mal noch lsof ... wobei diskN dann disk1, disk2, ... wäre lsof -a /mnt/diskN
September 13, 20241 yr Author Motioneye ist nicht mehr installiert. Den Share kann ich auch löschen. Quote lsof -a /mnt/diskN 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#
September 13, 20241 yr Ich bin jetzt mal nur kurz über den Thread geflogen. Handelt es sich bei den Platten um SAS Platten?
September 13, 20241 yr Author 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 Edited September 13, 20241 yr by Dexter
September 13, 20241 yr Ein Schuss ins blaue. Hast du eventuell irgendwelche der Shares in der Nextcloud verfügbar gemacht?
September 13, 20241 yr 1 hour ago, Dexter said: Die Parität (sde) hat es geschafft und ist schon länger im Spin Down. ok, dann sind es nur read Aufrufe, wobei eher "ich schau mal nach ..." ich hab mir jetzt mal die logs angeschaut, da sieht man nicht wirklich einen Auslöser plugin open files läuft, das zeigt nur aktive an ... was im Moment gerade auf ist, ich würde wenn dann mal eher auf file activity gehen und da schauen. wobei ich jetzt erstmal einen anderen Ansatz testen würde, plugin open files ex. erstmal alle VM's und Docker's stoppen, schauen was passiert, wenn die disks aus gehen und aus bleiben, one by one starten und schauen was auf die disk/s zugreift.
September 13, 20241 yr Author Quote Ein Schuss ins blaue. Hast du eventuell irgendwelche der Shares in der Nextcloud verfügbar gemacht? 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.
September 13, 20241 yr Ich geh mal davon aus, das deine Platten nicht über USB angeschlossen sind. Das Problem hatte ich anfangs mal mit meinem ersten Aufbau und da hatte ich die Platten per USB angeschlossen gehabt.
September 14, 20241 yr Community Expert 42 minutes ago, zero_neverload said: Ich geh mal davon aus, das deine Platten nicht über USB angeschlossen sind. Also ich sehe in seiner Diagnostics 3x WD HDD, 1x Seagate HDD, 1x USB Stick und eine NVMe SSD (mit btrfs). Das Mainboard scheint das Gigabyte GA-H270N-WIFI mit 6 SATA Ports zu sein. Dass man bei der Konstellation externe USB Gehäuse verwenden könnte ist zwar möglich, aber würde ich wohl eher als ausgeschlossen annehmen. Edited September 14, 20241 yr by DataCollector
September 14, 20241 yr Hast du im BIOS diesen HDD Smart-Check ausgeschaltet? Gibt doch Mainbords die rödeln von selbst auf den Platten rum um deren Zustand zu checken. Das weckt dir dann natürlich auch ständig die Platten auf.
September 14, 20241 yr Author 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. Quote Hast du im BIOS diesen HDD Smart-Check ausgeschaltet? 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. Quote Ich geh mal davon aus, das deine Platten nicht über USB angeschlossen sind. Das Problem hatte ich anfangs mal mit meinem ersten Aufbau und da hatte ich die Platten per USB angeschlossen gehabt. 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? Edited September 14, 20241 yr by Dexter
September 14, 20241 yr 24 minutes ago, Dexter said: Deinstallation von File Aktivity hatte nichts gebracht. du solltest das plugin "open files" weg machen und DAFÜR mal das plugin "file activity" testen 27 minutes ago, Dexter said: Vielleicht mal Unraid neu aufsetzen? brauchst ja nicht neu machen, zum Test, nen anderen Stick, Trial licence, starten und schauen was passiert wobei ich erstmal schauen würde ob file activity was anzeigt
September 14, 20241 yr Author 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
September 14, 20241 yr 1 hour ago, Dexter said: mir garnichts angezeigt auch wenn ich Dateien Lese und Schreibe. 1 hour ago, Dexter said: 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'. da siehst du warum ... am Einfachsten, Tipps und Tweaks nutzen ... da kann man den Wert per GUI dann setzen bei Bedarf
September 15, 20241 yr Author 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.
April 8Apr 8 Hast du die Ursache gefunden? Mich buggt das gleiche Problem. Selbst wenn alle Docker/VM ausgeschaltet sind dreht eine Platte immer wieder hoch.
April 8Apr 8 3 hours ago, Aluavin said:Selbst wenn alle Docker/VM ausgeschaltet sind dreht eine Platte immer wieder hochund auch keine plugins aktiv ? und auch kein zfs ?wenn nichts passiert ist das sehr ungewöhnlich, bei zfs normal falls das genutzt wird was klar sein sollte.
April 22Apr 22 Nein, Plattens sind alle xfs. In dem Fall war es aber die Docker-File, die aus irgendeinem Grund im Data-Pool gelandet ist, statt im cache pool.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.