Clepto

This is the solution, thank you very much for your effort JorgeB! Now everything works as intended and I finally know the reason for the spin ups and don't have to assume anymore that my server is cursed ^^

Das Problem hat sich tatsächlich nach langer Zeit beheben lassen und es gab im englischsprachigen Unraid Forum auch ein paar User die davon betroffen waren. Nach dem Befehl zfs set atime=off POOLNAME bleiben die Platten nun endlich aus und verhalten sich so wie sie sollen, getestet mit Unraid 7.2.3. Unter Unraid 7.2.3 selbst tritt das Problem immer noch auf, ich habe eine Platte von XFS wieder in ZFS formatiert und nach 24h lief diese wieder an, nach dem ZFS set Befehl ist dies jedoch behoben. Von daher kann man nur hoffen das zukünftige Unraid Versionen diesen Fehler beheben werden. Lösung

Das Monitoring ist nicht ausgeschaltet da es durch Unraid Softwareseitig natürlich aktiviert ist. Die Prüfung im BIOS ist nutzlos und verhindert evtl. nur bei einem Neustart des Servers durch die POST Checks das Hochfahren dessen. Meine Datenträger weisen keinerlei Fehler auf, nur mal so als Info.

My crontab for root looks like this # Generated docker monitoring schedule: 10 0 * * * /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate check &> /dev/null # Generated system monitoring schedule: */1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null # Generated mover schedule: 40 3 1 * * /usr/local/sbin/mover start |& logger -t move # Generated plugins version check schedule: 10 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck &> /dev/null # Generated Unraid OS update check schedule: 11 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null # CRON for CA background scanning of applications 44 * * * * php /usr/local/emhttp/plugins/community.applications/scripts/notices.php > /dev/null 2>&1 The other ones for cron.daily, hourly, weekly and monthly are empty.

Scrub habe ich im Moment komplett deaktiviert, genauso wie Autotrim. Den Mover habe ich auf den längsten Zeitraum von einem Monat gesetzt.

There are no active or open connections at the moment, i've tried to leave the server for hours without an ethernet cable and the disks also spun up. I can't remeber the exact time when i've formatet my HDDs in ZFS, but maybe 15:44 and 18:59 are the exact times when they finished? Sounds weird, iknow ^^ But i can't explain that otherwise, seems like there is a tag in ZFS which triggers checks or something. Some people here already complaint about many reads and writes on ZFS disks, i've read all the threads about it, but there wasn't an clear answer why this happens? When my disks spin up daily, I also have some reads and writes (disk statistics counter), i've tried to trace that with the File Activity Plugin and also Open Files, but there were no entries.

Genau, keine Plugins aktiv momentan bzw. schon ausgeschlossen. Appdata Backup hatte ich auch als noch aktiv auf 2 Uhr gesetzt. Aktuell ist SMART im BIOS deaktiviert, diesen Tipp habe ich lustigerweise mal in dem Energiespar Thread auch als Hinweis von dir gelesen, weil es sonst die Platten aufwecken könnte. Vor ein paar Monaten war das noch standardmäßig an, allerdings hat es die Platten soweit ich beurteilen kann bei meinem Board nie hochgefahren. Ich warte noch ein wenig und versuche dann meine derzeit leere Platte wieder in XFS zu formatieren, es wäre aber sehr merkwürdig falls ein Dateisystem sowas auslösen kann.

Der BIOS Reset ohne ändern der default Einstellungen hat übrigens auch nicht funktioniert. Habe auch mal die Uhr im BIOS 3 Stunden nach hinten gestellt um zu sehen ob diese entscheidend für die spin ups ist, allerdings hat es nichts geändert. Ich kann mitlerweile aber sagen das es was bringt die Unraid Systemzeit zu ändern um das Ganze zu beinflussen, das konnte ich nach erneutem testen herausfinden. Eine Änderung um -3h zögert die spin ups hinaus um die 3h, also wenn die verstellte Uhr bsp. 15:44 Uhr erreicht dann fahren die Platten hoch, während es eigentlich 18:44 Uhr reale Zeit ist. Bin kurz davor meine Festplatten wieder in XFS zu formatieren oder zumindest erstmal eine die eh leer ist, um zu testen ob es dann wieder aufhört. Ich würde es mir nur gerne erklären können woher dieses Verhalten kommt, irgendein Prozess oder Configfile muss in Verbindung mit ZFS ja dafür verantwortlich sein?

Yes, i took a new flashdrive and created a new install with the Unraid USB Creator with the newest stable 7.0.1 release. There where no configs from the previous flashdrive imported. After that I‘ve reassigned my drives with my parity marked as valid and created my shares and settings for dockers and vms new by hand. So the problem occurs again with the new install, even without plugins and modified configs on the flashdrive.

Hey guys, with the release of Unraid 7.0.1 I've formated all my drives in ZFS and added a new ZFS mirror cache pool with two Sandisk Ultra 3D SSDs. Since that, all my drives spin up twice a day exactly at the same times. This happens every day and stresses my three HDDs unessescary and ruins one of the major benefits of Unraid for an silent and power efficient homeserver. System Spes: CPU: Intel Core i9 9900 RAM: 64GB DDR-4 3200 Kingston Fury Beast (2x32GB, JEDEC 2400) Mainboard: Asrock H370M-ITX/ac (latest BIOS P4.30) Additional NIC: Dual 2.5G Realtek RTL8125 (rev 5) PSU: Corsair SF450 Case: Fractal Node 304 The disks spin up every day at 15:44 CEST and 18:59 CEST, the first one spins up all disks with the exclusion of disk1 (sdb) and the second one only disk2 (sdc) and the parity. All shares for docker, vms and also the libvirt and docker.img and the system shares are configured to be on my NVME SSD, no shares with permanent acces are configured to be on my array. I've tried all this things to solve the problem, with no sucess so far disbled/uninstalled all plugins disabled vm manger and docker unplugged ethernet cables created a new unraid flashdrive with a trial license, with minimal config without plugins etc. only docker, vms and my shares where configured BIOS reset with unchanged default settings checked my userscripts checked mover and autotrim downgraded from 7.0.1 to 7.0.0 several server restarts changed the clock of BIOS and Unraid itself -3h I really have no idea what triggers the disks to spin up, none of my actions stopped the spin ups. Only the change of the system time to -3h in Unraid changed the behavior, with that my disks spin up 3 hours later than usual, but the exact time for the spin up stays the same. Changing the time in BIOS didn't changed anything. I have an unraid offsite backup server with almost the same config and also all disks configured as ZFS and this server does not spin up the disks twice a day. The hardware is differnt, its an amd AM4 system, but besides that there is do difference. The disks in my offsite backup server where formated to ZFS with Unraid 6.12.0 that integratet ZFS for the first time, now the version of this server is the latest 7.0.1 release, and I've no problems. My current server with the spin up prolems where 7.0.1 when I've formated the disks to ZFS, maybe it's a bug in ZFS that persists in the newest Unraid version? It is also strange, that even with a new Unraid flashdrive the problem persists, without any modified config files on the flashdrive and plugins etc. Does anyone have a idea what can trigger the disks to spin up at the same times every day? I'am very curious what is causing this, there must be a process or something hardcoded anywhere, but I've no clue where to look further? tower-diagnostics-20250401-2059.zip

Danke für die Antwort und die Erklärung. Ich werde mein Glück mal zusätzlich im enlischsprachigen Bereich versuchen und auch nach open zfs recherchieren. Habe es jetzt mit einem BIOS reset probiert und werde mal abwarten ob es wieder auftritt und es evtl. nicht doch ein Hardware Phänomen ist.

Ja das wäre möglich, ich habe vergessen zu erwähnen das ich noch einen Unraid offsite Backup Server ebenfalls mit ZFS Platten (3 Stück) im Array habe und diese schlafen permanent und fahren nicht zweimal täglich zur selben Zeit hoch. Selbst wenn ZFS solche Checks pro Tag benötigt, dann wäre es interessant zu wissen wo die Zeiten dafür festgelegt werden. Selbst ein Neustart beeinflusst das Verhalten meines Servers mit dem Problem nicht. Ich finde schon das es auch Vorteile hat ZFS im Array einzusetzen, alleine durch die Komprimierung konnte ich fast 80GB an Speicherplatz einsparen, das finde ich schon ordentlich. Auch wenn ich aktuell ZFS Send und Receive nicht auf dem Array einsetze, kann ich es mir nützlich für die Zukunft vorstellen. Was ich festgestellt habe ist das sobald ein lesender Zugriff auf eine Disk stattfindet, die Parity nach einer gewissen Zeit/Dateien mit anläuft und auch Schreibzugriffe stattfinden. Das ist mit XFS nicht passiert. Ich habe bis jetzt auch noch keine Erklärung gefunden was dort genau geschrieben wird, hat es was mit den Checksummen zu tun?

Hallo Leute, ich habe meine Disks im Array zum 7.0.1 Update von XFS auf ZFS umgestellt und um einen ZFS Pool mit zwei neuen SSDs (Sandisk Ultra 3D) ergänzt. Meine NVME SSD habe ich ebenfalls von XFS auf ZFS umgestellt, sodass jetzt alle Datenträger ZFS formatiert sind. Das Umziehen der Daten habe ich mit Unbalanced erledigt, so wie es in dem SpaceinvaderOne Video zum Unraid 7 Release beschrieben ist. Seitdem habe ich das Problem das alle Datenträger täglich zweimal am Tag gestartet werden ohne ersichtlichen Grund, einmal um 14:44 Uhr und um 17:59 Uhr. Seit der Umstellung auf Sommerzeit haben sich die Zeiten um +1h geändert, also auf 15:44 und 18:59 Uhr. Um 15:44 Uhr ist Disk1 (sdb) die einzige die nicht mit angeht, alle anderen inklusive aller SSDs gehen mit an, um 18:59 Uhr bleibt Disk2 (sdc) dafür aus und Disk1 + Parity (sdd) gehen mit an, sämtliche Cache SSDs (bis auf die NVME die ua. wegen Docker immer an ist) bleiben diesmal auch aus. Auf dem Array liegen keine Shares oder libvirt-, docker.imgs für Docker, VM Manager oder anderen systemrelevanten Dingen, diese liegen alle auf den SSDs. Als die Array Disks noch mit XFS formatiert waren, gab es hier nie Probleme damit das HDDs aus dem nichts angelaufen sind. Folgendes habe ich schon versucht Plugins deaktiviert vorher auch mit File Activity Plugin versucht etwas herauszufinden, es gab aber keine Zugriffe aufs Array Docker und VM Manager deaktiviert Netzwerkkabel entfernt Neuen Unraid USB-Stick erstellt und alles neu eingerichtet ohne Plugins, sondern nur lauffähiger Zustand mit den Dockern, Shares und Array Systemzeit in Unraid geändert um -3h, Platten starten trotzdem zweimal täglich Cronjobs kontrolliert Userscripts kontrolliert Mover Autotrim Ich habe langsam echt keine Ahnung mehr was ich noch machen kann, es scheint so als würde irgendwo ein Timer laufen der sogar merkt. ob die Platten schon einmal Nachmittags oder Abends gelaufen sind. Als ich die Systemzeit (NTP off, manuelle Zeit) um -3h änderte, und 15:44 Uhr liefen die Platten vorher bereits an, dann liefen sie nach der Zeitänderung als der Zeitpunkt wieder erreicht war nicht erneut an. Der Abendliche run von Disk1 findet dann aber mit der geänderten Zeit statt, obwohl die reale Zeit abweicht. Das ist auch das einzige was ich erreichen konnte als ich die Systemzeit geändert habe, somit liefen die Disks dann zur realen Zeit um ca. 12:55 und 15:59 Uhr an. Wenn ich die Systemzeit in Unraid ändere, ändert sich ja auch die hwclock, allerdings steht im BIOS selber weiterhin die alte Zeit die nicht geändert wird. Sollte sich beim verwenden von hwclock nicht auch die Zeit im BIOS mit anpassen? Ich wäre über Hinweise wirklich dankbar, ich bin echt hartnäckig was Probleme angeht, aber mein Server scheint einfach nur verflucht zu sein und ich habe keine Ideen mehr 🙁 Vor allem da die Probleme auch mit dem neuen Unraid Stick bestehen, obwohl alles neu ist kann ich echt nicht nachvollziehen. Der ARC Cache kann es denke ich nicht sein, der kann ja nicht täglich immer zur selben Zeit erneuert werden, bei insgesamt 64GB RAM ist dieser mit Werten um die 2GB nicht mal ansatzweise ausgereizt von den Standardmäßig gesetzten 8GB ARC Cache in Unraid. tower-diagnostics-20250401-2059.zip