Spindown in Openmediavault nicht möglich (2024)

Hallo liebes Forum,

Ich habe in openmediavault das Problem das die HDDs (4x 8TB) nicht mehr in den Spindown gehen wenn ein Dateisystem mit RAID eingerichtet ist und über SMB freigegeben wird, am anfang ging der Spindown noch. Egal was ich einstelle (Testweise 5min) Spindown nicht möglich. Zudem habe ich beobachtet das alle 10-15 sekunden auf die HDDs ganz kurz zugegriffen wird, man hört alle 10-15 sekunden für ca. 1sek den Lese/Schreibkopf der HDD. Es hat den anschein das irgendwelche ständigen zugriffe auf die HDD ein Spindown verhindern, das Trennen des Netzlaufwerk unter Windows hat in Openmediavault mit den ständigen zugriffen nichts verändert. Ist es überhaubt möglich mit Openmediavault die HDDs zuverlässig in den Spindown zu versetzen auch wenn SMB aktiv ist?

Mein System:
ASUS Prime A520M-K
AMD Ryzen 5 Pro 3400GE
16GB DDR4 RAM
128GB NVMe SSD
4x 8TB Seagate IronWolf NAS HDDs

Wenn jemand eine idee hat was ich noch versuchen könnte wäre ich sehr dankbar😊

LordHelmchen200 schrieb:

Wenn jemand eine idee hat was ich noch versuchen könnte wäre ich sehr dankbar😊

Zum Vergrößern anklicken....

ich nutze jetzt omv nicht, aber zum Ausschluss würde ich das mal deaktivieren

ansonsten käme es ja noch drauf an was auf den platten liegt, nutzt man beispielsweise Docker und hat seine persistent appdata da liegen ... bei laufenden Dockers, wird da nie was in den spindown gehen, gleiches für VM's und co ...

sprich, es muss auf jeden Fall ein "Datengrab" sein

das omv System läuft auch auf einer separaten disk ? im RAM ? ...

alturismo schrieb:

sprich, es muss auf jeden Fall ein "Datengrab" sein

Zum Vergrößern anklicken....

Ja genau, Docker oder VMs nutze ich nicht

Ergänzung (8. August 2024)

alturismo schrieb:

das omv System läuft auch auf einer separaten disk ? im RAM ? ...

Zum Vergrößern anklicken....

Ja OMV läuft seperat auf der NVMe SSD

Ergänzung (8. August 2024)

TrueNAS will ich nicht nutzen da dort der Stromverbrauch bei 31W trotz Spindown liegt, in omv liegt der verbrauch bei 21W wenn Spindown geht.

EDIT:
Beziehungsweise habe ich nciht herausgefunden wie ich den verbrauch in TrueNAS reduzieren kann im leerlauf

Das ständiges Start/Stop für HDDs eher ungesund ist, weißt du? (Kommt aber natürlich darauf an, wie oft.)
Leuten, die das NAS selten nutzen, würde ich eher empfehlen, es bei Bedarf zu starten bzw. bestimmte Zeiten festzulegen, in denen das NAS aktiv sein soll.

Bei Spindown hast du m.W. immer den Nachteil, dass du die SMART-Checks deaktivieren musst - was auch nicht optimal ist.

hier ist empfehlenswert zu schauen welcher prozess die disk wach hält. das kannst du im terminal mit fatrace machen. wenn du dann weißt welcher prozess es ist, kann man schritte unternehmen das zu unterbinden, vorher ist es nur blindes rumgestochere.

https://unix.stackexchange.com/questions/72027/iotop-but-for-particular-disk/701656#701656

Banned schrieb:

Bei Spindown hast du m.W. immer den Nachteil, dass du die SMART-Checks deaktivieren musst - was auch nicht optimal ist.

Zum Vergrößern anklicken....

Das, oder dass intervall wann geprüft werden soll zu vergrößern

Ergänzung (8. August 2024)

Banned schrieb:

Das ständiges Start/Stop für HDDs eher ungesund ist, weißt du?

Zum Vergrößern anklicken....

Das weiß ich, ich hätte das dann eher auf mehrere Stunden gestellt. Eine andere möglichkeit Strom zu sparen wäre mit so einem Board hier
https://www.kleinanzeigen.de/s-anzeige/n100-nas-motherboard-17x17cm-8gb-ram/2829925058-225-354

Ergänzung (8. August 2024)

honky-tonk schrieb:

hier ist empfehlenswert zu schauen welcher prozess die disk wach hält. das kannst du im terminal mit fatrace machen.

Zum Vergrößern anklicken....

Ah danke werde ich ausprobieren

Banned schrieb:

Bei Spindown hast du m.W. immer den Nachteil, dass du die SMART-Checks deaktivieren musst - was auch nicht optimal ist.

Zum Vergrößern anklicken....

wie auf dem screenshot aus #2 zu sehen kann man die abfrage der smartdaten so begrenzen, dass sie nur bei laufender disk passieren.

LordHelmchen200 schrieb:

Eine andere möglichkeit Strom zu sparen wäre mit so einem Board hier

Zum Vergrößern anklicken....

jap die sind relativ sparsam, aber auch dort müssen die HDDs geparkt werden, damit es sparsam wird. ggf bringt der boardwechsel kaum was wenn die software nach wie vor alle 10sec die hdds aufweckt.

wenn's um stromsparen geht musste auch schauen dass die CPU in die hohen C/P states kommt oder ob PCIE devices das unterbinden. lässt sich gut mit powertop prüfen und das PCI gerät mit lspci herausfinden https://forums.unraid.net/topic/111...led-in-ubuntu/?do=findComment&comment=1053964

ich hab noch eine kurze Frage am Rande, ich habe zum testen 2 HDDs in ein RAID gestellt, nun wollte ich den RAID auflösen in openmediavault wohl nicht möglich HDDs lassen sich nicht plattmachen. Also habe ich kurz Hand den Rechner über ein Windows installationsdatenträger gestartet und mit Diskpart den Clean befehl gemacht, openmediavault neu installiert HDDs lassen sich immernoch nicht löschen.

Das seltsame, nachdem ich die HDDs mit dem Diskpart Clean befehl plattgemacht habe, sagte das openmediavault installations Setup das die HDDs immernoch im einem Software RAID sind....WTF, wie soll das möglich sein hier bin ich überfragt

0x8100 schrieb:

See Also

OpenMediaVault vs. TrueNAS (FreeNAS) in 2024 - WunderTech

wie auf dem screenshot aus #2 zu sehen kann...

Zum Vergrößern anklicken....

Jo, hätte mal das Kleingedruckte lesen sollen.
Bei TrueNAS werden die Disks durch das Intelvall aufgeweckt - hier ist das wohl nicht der Fall.

PS: @LordHelmchen200 "Plattmachen" und einen RAID-Verbund auflösen sind zwei Paar Schuhe. Ich habe keine Ahnung von OMV - aber einen RAID-Verbund sollte man dort auflösen können (dabei werden dann normalerweise auch die Daten gelöscht).

Am Ende wird's wohl leider so laufen müssen:

https://www.diskinternals.com/raid-recovery/how-to-remove-software-raid-with-mdadm/

Hätte jetzt gedacht, das ginge auch einfach übers GUI - aber scheinbar nicht.

Banned schrieb:

Hätte jetzt gedacht, das ginge auch eigentlich übers GUI - aber scheinbar nicht.

Zum Vergrößern anklicken....

Da kommt nur eine Fehlermeldung

@Banned meine fresse ist Linux Kompliziert, mann muss mit sudo cat /proc/mdstat die RAID-Verbunde auflisten und den RAID-Verbund Stoppen mit sudo mdadm --stop /dev/mdX und mit sudo mdadm --remove /dev/mdx Löschen. Dann lässt sich die Festplatte auch in der GUI Löschen. Da hab ich als eingefleischter Windows Nutzer wieder was dazu gelernt.

In der GUI ein button hinmachen der heißt RAID-verbund auflösen ist wohl zu Kompliziert (sowas ähnliches gibt es, ist aber ausgegraut), danke openmediavault

LordHelmchen200 schrieb:

Linux Kompliziert

Zum Vergrößern anklicken....

das liegt wohl eher am OMV, dass die den button nicht haben.

honky-tonk schrieb:

dass die den button nicht haben

Zum Vergrößern anklicken....

die haben zwar einen Button dafür, aber ohne Funktion, weil ausgegraut

honky-tonk schrieb:

hier ist empfehlenswert zu schauen welcher prozess die disk wach hält. das kannst du im terminal mit fatrace machen.

Zum Vergrößern anklicken....

Also so langsam fange ich an Linux zu hassen, ich habe fatrace instaliert mit sudo und lässt sich nicht ausführen, als rückmeldung bekomme ich nur das der Befehl nicht gefunden wurde...dann doch lieber blindes rumgestochere....

@LordHelmchen200 das klingt komisch.

gib nochmal genau die schritt und fehlermeldungen an die kommen.

normalterweise müsste

sudo apt install fatrace

und dann

sudo fatrace

in der console genügen

wenn er den befehl nicht finden kann hat wohl die installation nicht geklappt

honky-tonk schrieb:

sudo apt install fatrace

Zum Vergrößern anklicken....

oh danke, ich hab das vorher so gemacht sudo apt-get update sudo apt-get install fatrace

Ergänzung (8. August 2024)

honky-tonk schrieb:

fatrace

Zum Vergrößern anklicken....

geht nur mit sudo

Ergänzung (8. August 2024)

honky-tonk schrieb:

hier ist empfehlenswert zu schauen welcher prozess die disk wach hält. das kannst du im terminal mit fatrace machen.

Zum Vergrößern anklicken....

So ich habe das endlich hinbekommen, allerdings ein ewig langes Protokoll das ständig größer wird, ich kann damit leider überhaubt nichts anfangen, hier ein ausschnitt:

free(53981): R /usr/lib/x86_64-linux-gnu/libc.so.6
free(53981): O /usr/lib/x86_64-linux-gnu/libsystemd.so.0.35.0
free(53981): R /usr/lib/x86_64-linux-gnu/libsystemd.so.0.35.0
free(53981): O /usr/lib/x86_64-linux-gnu/libcap.so.2.66
free(53981): R /usr/lib/x86_64-linux-gnu/libcap.so.2.66
free(53981): O /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.4.1
free(53981): R /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.4.1
free(53981): O /usr/lib/x86_64-linux-gnu/liblzma.so.5.4.1
free(53981): R /usr/lib/x86_64-linux-gnu/liblzma.so.5.4.1
free(53981): O /usr/lib/x86_64-linux-gnu/libzstd.so.1.5.4
free(53981): R /usr/lib/x86_64-linux-gnu/libzstd.so.1.5.4
free(53981): O /usr/lib/x86_64-linux-gnu/liblz4.so.1.9.4
free(53981): R /usr/lib/x86_64-linux-gnu/liblz4.so.1.9.4
free(53981): O /usr/lib/x86_64-linux-gnu/libgpg-error.so.0.33.1
free(53981): R /usr/lib/x86_64-linux-gnu/libgpg-error.so.0.33.1
free(53981): C /etc/ld.so.cache
free(53981): O /usr/lib/locale/locale-archive
free(53981): O /etc/locale.alias
free(53981): R /etc/locale.alias
free(53981): C /etc/locale.alias
free(53981): O /usr/lib/locale/C.utf8/LC_IDENTIFICATION
free(53981): O /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
free(53981): O /usr/lib/locale/C.utf8/LC_MEASUREMENT
free(53981): O /usr/lib/locale/C.utf8/LC_TELEPHONE
free(53981): O /usr/lib/locale/C.utf8/LC_ADDRESS
free(53981): O /usr/lib/locale/C.utf8/LC_NAME
free(53981): O /usr/lib/locale/C.utf8/LC_PAPER
free(53981): O /usr/lib/locale/C.utf8/LC_MESSAGES
free(53981): C /usr/lib/locale/C.utf8/LC_MESSAGES
free(53981): O /usr/lib/locale/C.utf8/LC_MESSAGES/SYS_LC_MESSAGES
free(53981): O /usr/lib/locale/C.utf8/LC_MONETARY
free(53981): O /usr/lib/locale/C.utf8/LC_COLLATE
free(53981): O /usr/lib/locale/C.utf8/LC_TIME
free(53981): O /usr/lib/locale/C.utf8/LC_NUMERIC
free(53981): O /usr/lib/locale/C.utf8/LC_CTYPE
free(53981): C /usr/bin/free
free(53981): C /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
free(53981): C /usr/lib/locale/C.utf8/LC_IDENTIFICATION
free(53981): C /usr/lib/locale/C.utf8/LC_MEASUREMENT
free(53981): C /usr/lib/locale/C.utf8/LC_TELEPHONE
free(53981): C /usr/lib/locale/C.utf8/LC_ADDRESS
free(53981): C /usr/lib/locale/C.utf8/LC_NAME
free(53981): C /usr/lib/x86_64-linux-gnu/libproc2.so.0.0.1
free(53981): C /usr/lib/x86_64-linux-gnu/libc.so.6
free(53981): C /usr/lib/x86_64-linux-gnu/libsystemd.so.0.35.0
free(53981): C /usr/lib/x86_64-linux-gnu/libcap.so.2.66
free(53981): C /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.4.1
free(53981): C /usr/lib/x86_64-linux-gnu/liblzma.so.5.4.1
free(53981): C /usr/lib/x86_64-linux-gnu/libzstd.so.1.5.4
free(53981): C /usr/lib/x86_64-linux-gnu/liblz4.so.1.9.4
free(53981): C /usr/lib/x86_64-linux-gnu/libgpg-error.so.0.33.1
free(53981): C /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
free(53981): C /usr/lib/locale/C.utf8/LC_PAPER
free(53981): C /usr/lib/locale/C.utf8/LC_MESSAGES/SYS_LC_MESSAGES
free(53981): C /usr/lib/locale/C.utf8/LC_MONETARY
free(53981): C /usr/lib/locale/C.utf8/LC_COLLATE
free(53981): C /usr/lib/locale/C.utf8/LC_TIME
free(53981): C /usr/lib/locale/C.utf8/LC_NUMERIC
free(53981): C /usr/lib/locale/C.utf8/LC_CTYPE
free(53981): C /usr/lib/locale/locale-archive
sh(53980): C /usr/bin/dash
sh(53980): C /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
sh(53980): C /usr/lib/x86_64-linux-gnu/libc.so.6
omv-engined(53977): O /usr/share/php/openmediavault/system/cpu.inc
omv-engined(53977): R /usr/share/php/openmediavault/system/cpu.inc
omv-engined(53977): C /usr/share/php/openmediavault/system/cpu.inc
omv-engined(53977): O /usr/share/php/openmediavault/util/keyvaluefile.inc
omv-engined(53977): R /usr/share/php/openmediavault/util/keyvaluefile.inc
omv-engined(53977): C /usr/share/php/openmediavault/util/keyvaluefile.inc
omv-engined(53977): O /var/lib/openmediavault/dirtymodules.json
omv-engined(53977): RC /var/lib/openmediavault/dirtymodules.json
omv-engined(53982): RO /usr/bin/dash
sh(53982): R /usr/bin/dash
sh(53982): RO /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
sh(53982): O /etc/ld.so.cache
sh(53982): RO /usr/lib/x86_64-linux-gnu/libc.so.6
sh(53982): R /usr/lib/x86_64-linux-gnu/libc.so.6
sh(53982): C /etc/ld.so.cache
sh(53983): O /usr/bin/dpkg-query
dpkg-query(53983): R /usr/bin/dpkg-query
dpkg-query(53983): RO /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
dpkg-query(53983): O /etc/ld.so.cache
dpkg-query(53983): O /usr/lib/x86_64-linux-gnu/libmd.so.0.0.5
dpkg-query(53983): R /usr/lib/x86_64-linux-gnu/libmd.so.0.0.5
dpkg-query(53983): O /usr/lib/x86_64-linux-gnu/libc.so.6
dpkg-query(53983): R /usr/lib/x86_64-linux-gnu/libc.so.6
dpkg-query(53983): R /usr/lib/x86_64-linux-gnu/libc.so.6
dpkg-query(53983): C /etc/ld.so.cache
dpkg-query(53983): O /usr/lib/locale/locale-archive
dpkg-query(53983): O /etc/locale.alias
dpkg-query(53983): R /etc/locale.alias
dpkg-query(53983): C /etc/locale.alias
dpkg-query(53983): O /usr/lib/locale/C.utf8/LC_IDENTIFICATION
dpkg-query(53983): O /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
dpkg-query(53983): O /usr/lib/locale/C.utf8/LC_MEASUREMENT
dpkg-query(53983): O /usr/lib/locale/C.utf8/LC_TELEPHONE
dpkg-query(53983): O /usr/lib/locale/C.utf8/LC_ADDRESS
dpkg-query(53983): O /usr/lib/locale/C.utf8/LC_NAME
dpkg-query(53983): O /usr/lib/locale/C.utf8/LC_PAPER
dpkg-query(53983): CO /usr/lib/locale/C.utf8/LC_MESSAGES
dpkg-query(53983): O /usr/lib/locale/C.utf8/LC_MESSAGES/SYS_LC_MESSAGES
dpkg-query(53983): O /usr/lib/locale/C.utf8/LC_MONETARY
dpkg-query(53983): O /usr/lib/locale/C.utf8/LC_COLLATE
dpkg-query(53983): O /usr/lib/locale/C.utf8/LC_TIME
dpkg-query(53983): O /usr/lib/locale/C.utf8/LC_NUMERIC
dpkg-query(53983): O /usr/lib/locale/C.utf8/LC_CTYPE
dpkg-query(53983): O /var/lib/dpkg/status
dpkg-query(53983): R /var/lib/dpkg/status
dpkg-query(53983): C /var/lib/dpkg/status
dpkg-query(53983): O /var/lib/dpkg/updates
dpkg-query(53983): R /var/lib/dpkg/updates
dpkg-query(53983): R /var/lib/dpkg/updates
dpkg-query(53983): C /var/lib/dpkg/updates
dpkg-query(53983): RO /var/lib/dpkg/triggers/File
dpkg-query(53983): R /var/lib/dpkg/triggers/File
dpkg-query(53983): R /var/lib/dpkg/triggers/File
dpkg-query(53983): C /var/lib/dpkg/triggers/File
dpkg-query(53983): O /var/lib/dpkg/triggers/Unincorp
dpkg-query(53983): C /var/lib/dpkg/triggers/Unincorp
dpkg-query(53983): C /usr/bin/dpkg-query
dpkg-query(53983): C /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
dpkg-query(53983): C /usr/lib/locale/C.utf8/LC_IDENTIFICATION
dpkg-query(53983): C /usr/lib/locale/C.utf8/LC_MEASUREMENT
dpkg-query(53983): C /usr/lib/locale/C.utf8/LC_TELEPHONE
dpkg-query(53983): C /usr/lib/locale/C.utf8/LC_ADDRESS
dpkg-query(53983): C /usr/lib/locale/C.utf8/LC_NAME
dpkg-query(53983): C /usr/lib/x86_64-linux-gnu/libmd.so.0.0.5
dpkg-query(53983): C /usr/lib/x86_64-linux-gnu/libc.so.6
dpkg-query(53983): C /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
dpkg-query(53983): C /usr/lib/locale/C.utf8/LC_PAPER
dpkg-query(53983): C /usr/lib/locale/C.utf8/LC_MESSAGES/SYS_LC_MESSAGES
dpkg-query(53983): C /usr/lib/locale/C.utf8/LC_MONETARY
dpkg-query(53983): C /usr/lib/locale/C.utf8/LC_COLLATE
dpkg-query(53983): C /usr/lib/locale/C.utf8/LC_TIME
dpkg-query(53983): C /usr/lib/locale/C.utf8/LC_NUMERIC
dpkg-query(53983): C /usr/lib/locale/C.utf8/LC_CTYPE
dpkg-query(53983): C /usr/lib/locale/locale-archive
unknown(53982): C /usr/bin/dash
unknown(53982): C /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
unknown(53982): C /usr/lib/x86_64-linux-gnu/libc.so.6
nginx(873): W /var/log/nginx/openmediavault-webgui_access.log
rrdcached(877): W /var/lib/rrdcached/journal/rrd.journal.1723140898.381915
rrdcached(877): W /var/lib/rrdcached/journal/rrd.journal.1723140898.381915

Falls du @honky-tonk was erkennen kannst was die Ständigen HDD zugriffe auslöst wäre ich dir sehr dankbar, ich bin hier überfragt

dazu wäre es interessant zu wissen wo die HDDs gemounted sind. üblicherweise ist das /media oder /mnt unter linux. wenn du einfach "mount" aufrufst zeigt er dir alle mountpoints, da musst du nur den richtigen rausfischen.

wenn du den HDD pfad kennst wechselst du mit

cd /media/*hdd ordner*

in den ordner wo die HDD gemounted ist und rufst von dort

fatrace -c

auf. dann hast du nur zugriffe auf die aktuelle HDD.

du hast aktuell alle zugriffe auf root mit drin, was es natürlich unübersichtlich macht.

Ich bin jetzt durch das Auseinandersetzen und ausprobieren mit Openmediavault durch Zufall auf eine Lösung gestoßen.

Was ich gemacht habe:
Openmediavault Extras für eine Größere Auswahl an Plugins installiert dann das ZFS Plugin installiert.
Aus den 4HDDs ein Pool erstellt mit RAID-Z1 und es via. Samba Freigabe Freigegeben, wenn über Samba Daten auf das NAS geschrieben werden dann schalten die HDDs zuverlässig in den Spindown, hab das 10h ausprobiert zwischendurch immer mal wieder was Kopiert und gewartet, Spindown wird erfolgreich durchgesetzt, bei ZFS ist mir nämlich aufgefallen das das NAS im Leerlauf keine Ständigen HDD Zugriffe macht das den Spindown verhindert. Da ich eh ZFS nutzen wollte passt das.

Warum Openmediavault mit ZFS keine Zugriffe alle paar Sekunden macht im Leerlauf kann ich mir nicht erklären