NextcloudPi macht kein HDD Spinndown

Jump to last post
R

raiden

Neu angemeldet
Registriert
8 Mai 2019
Beiträge
52
Hallo Forum,

ich habe auf meinen PI 4 1GB NextcloudPi installiert und eine 2,5" WD HDD angeschlossen. Soweit läuft alles einwandfrei.

Jedoch macht die HDD kein Spinndown und läuft ständig durch.

Folgende Sachen habe ich schon Probiert, jedoch ohne Erfolg.

Vielleicht hat jemand eine Idee oder Rat was ich noch testen könnte oder wo der Fehler liegt.

Gruß
Raiden

1. Unter Admin bin ich von Cron auf Ajax gewechselt.

2. hdparm installiert und folgendes ausgeführt:

Überprüfung ob das Laufwerk hdparm unterstützt:
sudo hdparm -y /dev/sda = Ergebnis: /dev/sda: issuing standby command

Überprüft ob das Laufwerk write cache unterstützt: sudo hdparm -I /dev/sda | grep 'Write cache' = * Write cache

Dann sudo hdparm -B127 /dev/sda ausgeführt und dann in der hdparm.conf = sudo nano /etc/hdparm.conf
folgendes am Ende eingetragen:
/dev/sda {
write_cache = on
spindown_time = 120
}
 
@raiden: Sei froh, sonst muss man den Spindown manuell unterbinden.

Was Festplatten kaputt macht ist nicht der Dauerlauf - es ist das ständige SpinUp & SpinDown mit den resultierenden Temperaturschwankungen, weshalb man das bei Dauerläufern tunlichst abschaltet.
 
  • Thread Starter Thread Starter
  • #3
@Metal_Warrior: Wenn die HDD kein Spindown macht, verbraucht sie ja unnötig Strom.
Denn es wird nicht zwingend täglich ein Zugriff auf die Cloud erfolgen.
 
@raiden: Ich würde behaupten, wenn du 2-5mal pro Tag was anforderst (und das wird über kurz oder lang so sein, mit Cloud), dann geht deine HDD schneller hops mit SpinDown als ohne. Der Stromverbrauch bei 2,5"-Laufwerken ist selbst unter Last höchstens 2 Watt, das ist zu vernachlässigen.
 
Ich leg die HDDs meiner NAS und meines HTPC auch schlafen. Bei der NAS ist die HDD nur die Downloadplatte, die wird manchmal wochenlang nicht benutzt. Beim HTPC ist das schon problematischer, da der halt pro Tag auch mehrmals gebootet wird und die HDD dann auch immer anfährt. Kritisch seh ich das nicht. Die Platte ist jetzt 8 Jahre alt und zeigt keinerlei Probleme mit dem mehrmaligen Spin-Up/-Down pro Tag.

Zum eigentlichen Problem:
raiden: Hast du Zugriff auf die Konsole bei Deiner NAS. Dann installier Dir eines der vielen Diagnose-Tools, die da wären:
Finde den Prozess raus, der halt permanent auf die Platte zugreifen will und unterbinde das.

Heiße Kandidaten sind z.B. Systemd-Journal bzw. jegliche andere Logger. Dann wären da noch diverse Dienste, die irgendwas auf die Platte cachen oder permanent irgendwelche Configs schreiben.
 
Zuletzt bearbeitet:
  • Thread Starter Thread Starter
  • #6
@musv: Ja,SSH Zugriff ist aktiviert. Habe bis all die o.g. Sachen darüber gemacht.
Ich werde die Tools testen und gucken ob ich das Problem finde. Bericht folgt dann.

@@Metal_Warrior: Bisher sind es lediglich 3 Zugriffe die Woche. Kann durchaus sein, dass sich das in Zukunft ändert.
 
@musv: Naja, wie heiß die Voraussage aus einer einzigen Platte ist, überlass ich jetzt mal dir. Bei mir war die Samplegröße eher so um die 30 Dauerläufer (mit einem Ausfall nach 4 Jahren; Aussortierung nach 6-12 Jahren), und so 60 Teilzeitläufer, mit durchschnittlicher Lebenserwartung von eher um die 5-8 Jahre. Und auf Arbeit sind wir da im mittleren Hunderter-Bereich mit Ausfällen nach ca. 8-10 Jahren, wobei das auch andere Belastungen sind...

Ansonsten: Journald schreibt nicht auf externe Platten, wenn das Linux nicht völlig zusammengeschustert wurde; da tippe ich eher auf die NextCloud-Datenbank mit Indexern etc; die hat er ja ziemlich sicher dort liegen.
 
  • Thread Starter Thread Starter
  • #8
Bei der Installation der HDD im WebGui will NC die Datenbank auf die HDD kopieren. Hatte das bisher immer bejaht, da es auch so in den Tuts I'm Netz steht.
jedoch habe ich ein Beitrag im Netz gefunden, wo jemand dies nicht gemacht hat. Trotzdem macht seine Wdr HDD auch kein Spindown.
ich hatte jetzt noch Raspbian getestet um zu gucken die dort meine HDD behandelt wird. Auch hier geht wird sie nicht in den Spindown geschickt. Hatte hier nochmal hdparm und zusätzlich HD-idle getestet. Alles ohne Erfolg.

Liegt es vielleicht doch an die HDD? Wie verhält sich das ganze bei einer Ssd. Läuft diese dann immer oder hat sie auch eine Art Spindown?

@Metal_Warrior. Natürlich macht bei sehr häufigen Zugriff auf HDDs ein Spindown kein Sinn. Da ist der Verschleiß zu hoch bei permanenten hoch und runter fahren.
 
You do not have permission to view link please Anmelden or Registrieren
Ich hab nie mit NextCloud rumgespielt. Aber natürlich ergibt die Datenbankindexierung einen Sinn.

raiden schrieb:
ich hatte jetzt noch Raspbian getestet um zu gucken die dort meine HDD behandelt wird. Auch hier geht wird sie nicht in den Spindown geschickt. Hatte hier nochmal hdparm und zusätzlich HD-idle getestet. Alles ohne Erfolg. Liegt es vielleicht doch an die HDD?
Zum Vergrößern anklicken....
Mit welchem Befehl hast du's denn probiert? Auf meiner NAS hab ich mir dazu folgende UDEV-Regel angelegt:

/etc/udev/rules.d/10-disksleep.rules
Code:
Expand Collapse Copy 
SUBSYSTEM=="block", KERNEL=="sdb", RUN+="/sbin/hdparm -S 241 /dev/sdb"
Um die Platte mal nach 5 Sekunden in den Schlafmodus zu schicken, müsstest du die 241 in eine 1 abändern und hdparm natürlich erst mal ohne Udev-Regel testen. (
You do not have permission to view link please Anmelden or Registrieren
)

raiden schrieb:
Wie verhält sich das ganze bei einer Ssd. Läuft diese dann immer oder hat sie auch eine Art Spindown?
Zum Vergrößern anklicken....
Hab's grad mal ausprobiert:

Code:
Expand Collapse Copy 
root ~> hdparm -S 1 /dev/sda

/dev/sda:
 setting standby to 1 (5 seconds)

root ~> hdparm -C /dev/sda

/dev/sda:
 drive state is:  idle
Mein Notebook hat jetzt bestimmt alle sich rotierenden Teile in der SSD kurz mal angehalten. :p

Aber auch zu diesem Thema findet sich was im großen weiten
You do not have permission to view link please Anmelden or Registrieren
.
 
@raiden: Was mein Freund hier so eloquent sagen will: Bei SSDs gibt es keinen SpinDown, weil sie keine drehenden Teile hat (sie läuft immer, und braucht dabei auch weniger Strom als eine HDD).

Wie gesagt, ich würde den fehlenden SpinDown als Feature sehen, nicht als Problem.
 
  • Thread Starter Thread Starter
  • #11
Mir ist das vollkommen bewusst, dass eine SSD keine drehenden Teile hat.
Hätte ja sein können, dass bei nicht Gebrauch die Chips abgeschaltet werden.

--- [2019-10-12 11:51 CEST] Automatisch zusammengeführter Beitrag ---

@musv:

Das habe ich gemacht:

1. Unter Admin bin ich von Cron auf Ajax gewechselt.

2. hdparm installiert und folgendes ausgeführt:

Überprüfung ob das Laufwerk hdparm unterstützt:
sudo hdparm -y /dev/sda = Ergebnis: /dev/sda: issuing standby command

Überprüft ob das Laufwerk write cache unterstützt: sudo hdparm -I /dev/sda | grep 'Write cache' = * Write cache

Dann sudo hdparm -B127 /dev/sda ausgeführt und dann in der hdparm.conf = sudo nano /etc/hdparm.conf
folgendes am Ende eingetragen:
/dev/sda {
write_cache = on
spindown_time = 120

Habe diesen Beitrag im Netz gefunden und auch ausprobiert. Ohne Erfolg.

You do not have permission to view link please Anmelden or Registrieren


For the info.Im a Linux Newbie
 
Zuletzt bearbeitet:
Mal die Frage in den Raum geworfen: Was muß eine Festplatte haben, dass sie mit HdParm angesprochen und gesteuert werden kann? Oder gibt es da eine Liste von unterstützenden Herstellern/Modellen?

Wäre interessant für die Wahl bei NAS und oder generell für die Wahl von externen Speichermedien. Die alle "irgendwie" unterschiedlich arbeiten... mal Spin down, mal nicht. :unknown:
 
@theSplit: Ich wüsste keine HDD, die SpinDown nicht unterstützt. Tatsächlich resettet sich die Zeit, die für die Aktivierung des SpinDown verstreichen muss, aber bei jedem Zugriff wieder, d. h. musv hat schon recht, wenn er sagt, dass man da erstmal die verantwortlichen Dienste finden muss, welche die HDD nutzen.

Mal ne Frage an den TS: auf welchem Mountpoint hast du sie denn eingebunden?
 
  • Thread Starter Thread Starter
  • #14
Metal_Warrior; Mal ne Frage an den TS: auf welchem Mountpoint hast du sie denn eingebunden?[/QUOTE schrieb:
Wenn ich das richtig sehe über mount -l , dann ist die HDD über ,,/dev/sda1 on /media/username/.... " eingebunden.

Kann es sein, dass es doch vielleicht was mit dem Controller der HDD zu tun hat. Bisher war meine WD immer als ex4 formatiert.
AM Pi oder am Laptop blinkte immer die LED der HDD und sie wirkte etwas unruhig im Betrieb. Jetzt ist sie auf ntfs formatiert und die LED leuchtet konstant und sie ist laufruhig.

Zum Vergleich habe ich noch eine 2,5 HDD von Toshiba. Diese geht in den Spinndown. Egal ob sie als ext4 oder ntfs formatiert ist.
Zum Vergrößern anklicken....
 
Ich glaub, die Lösung ist viel trivialer. Wenn in der hdparm.conf was drinsteht, interessiert es das System herzlich wenig, wenn hdparm beim Booten nicht aufgerufen wird. Und ob und wie die hdparm.conf gelesen wird, hab ich nirgendwo gefunden.

Dazu hier auch das Arch-Wiki:
You do not have permission to view link please Anmelden or Registrieren

Die nutzen entweder eine Udev-Regel oder schreiben einen Systemd-Service, um hdparm aufzurufen.
 
@raiden: NTFS auf Linux ist ne dumme Idee. Aber das nur nebenbei.

Wenn sie in /media/username/xyz gemountet ist, dann ist das ein FUSE-Mount, also keiner, der direkt vom Kernel verwaltet wird, und das kann schon sein, dass dann öfter mal draufgeschaut wird.

Bei Debian wird die hdparm.conf von udev genutzt, d. h. daran dürfte es nicht liegen - es kann aber wie gesagt sein, dass der Mount selbst das Problem ist.
 
  • Thread Starter Thread Starter
  • #17
Das mit dem NTFS war einfach ein Test.

Gibt es denn eine sinnvolle Lösung mit dem Mount Punkt?
Muss man noch udev configurieren oder reichte der Versuch in der hdparm.conf?

Oder kurz und knapp die HDD einfach gegen eine SSD tauschen?
 
raiden schrieb:
1. Unter Admin bin ich von Cron auf Ajax gewechselt.
Zum Vergrößern anklicken....
You do not have permission to view link please Anmelden or Registrieren

Ich wusste nicht, was Ajax hier in dem Zusammenhang bedeutet. Wird aber im 2. Beitrag ganz gut erklärt. Demnach solltest du auch eher Cron bevorzugen. Auf meiner NAS hab ich Cronjobs übrigens ganz deaktiviert. Und wenn so recht überlege, nutze ich derzeit auf keinem System Cronjobs.

Metal_Warrior schrieb:
Wenn sie in /media/username/xyz gemountet ist, dann ist das ein FUSE-Mount,
Zum Vergrößern anklicken....
Inwiefern machst du anhand des Mountpoints den verwendeten Treiber (FUSE) aus? Nach der
You do not have permission to view link please Anmelden or Registrieren
wird nur festgelegt, dass dort Wechseldatenträger eingebunden werden sollen.

raiden schrieb:
Bisher war meine WD immer als ex4 formatiert.…Jetzt ist sie auf ntfs formatiert und die LED leuchtet konstant und sie ist laufruhig.
Zum Vergrößern anklicken....
Ergänzend dazu mal ein paar Hintergrundinfos, warum das 'ne blöde Idee ist:
Im Linux-Kernel werden haufenweise Dateisysteme unterstützt, u.a. EXT4, XFS, Reiser3, JFS, BRTFS, ISO 9660 (CDRom), UDF, FAT. Selbst BeOS-FS, Amiga-FS, HFS (Apple) sind dabei. Für alle anderen Sachen gibt's dann
You do not have permission to view link please Anmelden or Registrieren
als Schnittstelle, über die dann weitere Dateisystemtreiber, u.a.
You do not have permission to view link please Anmelden or Registrieren
angebunden werden können. Allen FUSE-basierten Treibern gemein ist, dass die Performance ziemlich mies ist. Die Zugriffsraten sind niedriger als bei Kerneltreibern, die CPU-Last geht stark hoch.

Wir verwenden auf Arbeit mittlerweile XFS als Standarddateisystem.

Metal_Warrior schrieb:
Bei Debian wird die hdparm.conf von udev genutzt, d. h. daran dürfte es nicht liegen - es kann aber wie gesagt sein, dass der Mount selbst das Problem ist.
Zum Vergrößern anklicken....
Dem
You do not have permission to view link please Anmelden or Registrieren
zufolge, wird dort hdparm als Init-Script gestartet. Das würde auch dem entsprechend, was auf meinem Rechner (Gentoo) im hdparm-Paket vorhanden ist. Also entweder muss eine UDEV-Regel für hdparm vorhanden sein unter /lib/udev/rules.d oder das Init-Script wird beim Systemstart aufgerufen.

Die hdparm.conf wird sehr vermutlich nicht gelesen, wenn die nachträglich geändert wird ohne Systemstart. In den Logs hab ich dazu allerdings auch nichts gefunden. hdparm scheint nichts zu loggen.
 
musv schrieb:
Inwiefern machst du anhand des Mountpoints den verwendeten Treiber (FUSE) aus? Nach der
You do not have permission to view link please Anmelden or Registrieren
wird nur festgelegt, dass dort Wechseldatenträger eingebunden werden sollen.
Zum Vergrößern anklicken....
Da steht der Username im Pfad - das ist ein ziemlich untrüglicher Hinweis ;)

Außerdem hat er als Anfänger sicher eine GUI, und zumindest Gnome mountet automatisch alle eingehängten Datenträger als FUSE in diesen Pfad rein. Ein System ohne GUI (Debian) mountet gar nicht selbstständig, und das, was Anfänger typischerweise machen, ist es entweder in /home/user/xyz zu mounten, oder irgendwo ins Rootverzeichnis rein. Kein Anfänger liest den FHS. Auf Arbeit muss ich sogar feststellen, dass selbst die Profis oft nichts damit anfangen können (da wird fröhlich selbst geschriebener Scheiß in /lib gepackt und neue Systemdienste loggen nach /home/Dienstname...).

Außerdem ist NTFS immer FUSE...

Wir verwenden auf Arbeit mittlerweile XFS als Standarddateisystem.
Zum Vergrößern anklicken....
ext4 und xfs nehmen sich kaum was; die Dateisysteme sind was Performance angeht kaum verschieden.

Dem
You do not have permission to view link please Anmelden or Registrieren
zufolge, wird dort hdparm als Init-Script gestartet.
Zum Vergrößern anklicken....
Debian bohrt gern Pakete auf (im Gegensatz zu Arch und Gentoo), um alte Funktionen weiterhin verfügbar zu halten, ganz nach Politik der Nonbreaking-Upgrades. Daher auch
You do not have permission to view link please Anmelden or Registrieren
 
  • Thread Starter Thread Starter
  • #20
@Metal_Warrior: Ja, ich benutze eine GUI.

Würde sich das ganze verhalten mit der HDD ändern, wenn ich auf Raspbian Lite (ohne GUI) umsteige und die HDD wie folgt mounte:

mkdir /media/hhd1

mount - t auto dev/sda1/ media/hdd1
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben