Festplatte ST3500320AS schläft nicht

OP #7433698
Lesenswert?

Hallo Forum, ich habe einen Linux-Server, welcher hier im Haus diverse Funktionen hat. Unter anderem ist da eine Festplatte ST3500320AS (Seagate Barracuda) einbaut, welche einmal täglich zum Backup benötigt wird. Damit sie während der restlichen Zeit nicht unnütz rum-idlet, habe ich sie per hdparm in den Spindown gesetzt. Das läuft jetzt schon Jahre so und schien bisher auch zu funktionieren. In der /etc/hdparm.conf habe ich eine Spindown-Time auf 120 gesetzt. Wenn ich den Status mit "hdparm -C" abfrage, kommt auch "drive state is: standby" zurück. Allerdings ist mir jetzt aufgefallen, dass die Platte warm ist. Also habe ich etwas rumgespielt und festgestellt, dass, wenn ich "hdparm -Y" (Sleep) ausführe, der Motor hörbar runterfährt. Dann wird sie auch kühl. Allerdings kann ich den Status so nicht abfragen. Wenn ich "hdparm -C" ausführe, dreht sie wieder hoch und sagt dann "standby".

Ich weiss leider nicht, ob sie das schon immer macht oder ob das Verhalten neu ist. Ist das evtl. bei dieser Platte normal? Wie kann ich das automatisieren, dass sie nach einigen Minuten in den Sleep geht?

Danke

#7433898
Lesenswert?

Rangi J. schrieb:

hat. Unter anderem ist da eine Festplatte ST3500320AS (Seagate Barracuda) einbaut, welche einmal täglich zum Backup benötigt wird. Damit sie während der restlichen Zeit nicht unnütz rum-idlet, habe ich sie per hdparm in den Spindown gesetzt.

Da gibt's/gab's mitunter Probleme.

Allerdings ist mir jetzt aufgefallen, dass die Platte warm ist. Also habe ich etwas rumgespielt und festgestellt, dass, wenn ich "hdparm -Y" (Sleep) ausführe, der Motor hörbar runterfährt. Dann wird sie auch kühl. Allerdings kann ich den Status so nicht abfragen. Wenn ich "hdparm -C" ausführe, dreht sie wieder hoch und sagt dann "standby".

smartctl verwenden, siehe auch: https://wiki.archlinux.org/title/Hdparm#Querying_the_status_of_the_disk_without_waking_it_up

Ich weiss leider nicht, ob sie das schon immer macht oder ob das Verhalten neu ist.

Vermutlich war das schon immer so.

#7433922
Lesenswert?

Erst ›umount‹, dann HD-sleep! Sonst wird sich immer irgend etwas bemüßigt fühlen, dann und wann auf die Platte zuzugreifen und sie in wilde kreisförmige Bewegungen zu versetzen.

Im Übrigen habe ich das gerade mal mit: Model=SAMSUNG HD154UI und auch mit Model=SAMSUNG HD103SJ versucht. ›-C‹ erweckt die Dinger bei mir nicht zum bewegten Leben, sondern meldet:

1
/dev/sdc:
2
drive state is:  active/idle

Erst ein echter Zugriff lässt die Motoren hörbar aufsummen und kreisen.

#7433945
Lesenswert?

Norbert schrieb:

Erst ›umount‹, dann HD-sleep! Sonst wird sich immer irgend etwas bemüßigt fühlen, dann und wann auf die Platte zuzugreifen und sie in wilde kreisförmige Bewegungen zu versetzen.

Im Übrigen habe ich das gerade mal mit: Model=SAMSUNG HD154UI und auch mit Model=SAMSUNG HD103SJ versucht. ›-C‹

Er hat ein spezifisches Problem mit seiner ollen SEAGATE HD, das genau für diese Modellreihe damals nicht untypisch war.

erweckt die Dinger bei mir nicht zum bewegten Leben, sondern meldet:/dev/sdc: drive state is: active/idle

Bei idle dreht der Spindelmotor. Genau das will er aber nicht.

Erst ein echter Zugriff lässt die Motoren hörbar aufsummen und kreisen.

Ich zitiere ihn noch mal:

Wenn ich den Status mit "hdparm -C" abfrage, kommt auch "drive state is: standby" zurück.

Er bekommt also "standby" zurückgemeldet und nach Product Manual sollte der Spindelmotor seiner HD jetzt stehen. Tut er aber in der Realität nicht. Erst wenn er die HD in "sleep" versetzt, steht der Motor. Damals ein bekanntes Problem. Möglich, daß es ein Firmwareupdate gab. Muß er mal recherchieren.

#7434030
Lesenswert?

Michael L. schrieb:

Er hat ein spezifisches Problem mit seiner ollen SEAGATE HD, das genau für diese Modellreihe damals nicht untypisch war.

Richtig.

In all den Jhren hätte das aber gefixed sein sollen, oder?

nicht. Erst wenn er die HD in "sleep" versetzt, steht der Motor. Damals ein bekanntes Problem. Möglich, daß es ein Firmwareupdate gab. Muß er mal recherchieren.

Nö. So einfach kann man es sich nicht machen. Unter (aktuellem) Windows funktioniert das, wie es soll. Mit exakt der angegebenen Platte überprüft! (Hatte ich zufällig noch in einer Elektronikschrott-Kiste rumliegen).

Und die Gegenprobe mit (aktuellem) Linux-Mint: verhält sich wie vom TO beschrieben, also definitiv FALSCH.

Das Problem ist also nicht die Platte oder deren Firmware, sondern Linux. Ende der Ansage.

Nur die Linux-Fanboys werden jetzt negative Bewertungen applizieren, das aber reichlich. Die, die wirklich Ahnung haben, würden vielleicht versuchen, nach all den vielen Jahren endlich das Problem zu fixen (wenn es sie selber beträfe)...

Aber: keiner dieser Klasse schreibt hier... Und ich bin nicht sicher, ob (außer mir) noch irgendwer davon hier noch liest. Und ich selber könnte es zwar lösen, aber habe keine Lust dazu. Nicht für so ein alte Gurke von HDD, die eigentlich niemand mehr braucht und auch bei mir eigentlich nur noch auf die Entsorgung gewartet hat...

#7434048
Lesenswert?

C-hater schrieb:

Nö. So einfach kann man es sich nicht machen. Unter (aktuellem) Windows funktioniert das, wie es soll. Mit exakt der angegebenen Platte überprüft! (Hatte ich zufällig noch in einer Elektronikschrott-Kiste rumliegen).

Und die Gegenprobe mit (aktuellem) Linux-Mint: verhält sich wie vom TO beschrieben, also definitiv FALSCH.

Ich könnte mir gut vorstellen das Windows hier evtl noch einen Workaround hinterherwirft. Denn, das sind ja nunmal alles Kommandos an die Platte die eigentlich Herstellerübergreifend sind. Wenn jetzt Linux an der Stelle was falsch machen würde, dann wären ALLE Platten, egal von wem betroffen.

Ich will hier auch kein Win/Linux Bashing betreiben. Ich benutz beides.

OP #7434109
Lesenswert?

Okay, okay, ich wusste ja nicht, das das hier solche Wellen wirft. Hatte auf irgend eine simple Lösung gehofft. Aber so.... Dann werd ich wohl mal eine andere Platte verwenden oder es einfach so weiter laufen lassen. Das ist dann eine Frage von "Never change a running system". Oder doch? Ich überlegs mir.

Alles klar, Danke für die Hinweise.

#7434257
Lesenswert?

Ich verstehe das Problem noch nicht so ganz. Du versetzt die Platte per hdparm -Y in den Standby, und das funktioniert auch wie gewünscht. Wenn du aber den Status abfragst, fährt sie dadurch wieder hoch. Das sollte sie zwar nicht, aber warum lässt du die Abfrage dann nicht einfach weg?

C-hater schrieb:

Er hat ein spezifisches Problem mit seiner ollen SEAGATE HD, das genau für diese Modellreihe damals nicht untypisch war.

Richtig.

In all den Jhren hätte das aber gefixed sein sollen, oder?

Vielleicht haben sie das ja mal gefixt. Hast du geschaut, ob die Firmware der Platte aktuell ist?

Nö. So einfach kann man es sich nicht machen.

Doch. Mit diesem Modell funktioniert es nicht, mit anderen schon. Keine der Platten, die ich im Einsatz habe, verhält sich so. Wie kann man da auf die Idee kommen, es könne keinen Zusammenhang mit diesem Modell bzw. dessen Firmware geben?

Nur die Linux-Fanboys werden jetzt negative Bewertungen applizieren, das aber reichlich.

Hauptsächlich allerdings auf Grund deines arroganten Tons.

Aber: keiner dieser Klasse schreibt hier... Und ich bin nicht sicher, ob (außer mir) noch irgendwer davon hier noch liest. Und ich selber könnte es zwar lösen, aber habe keine Lust dazu.

Dann kennst du die Details der Ursachen dieses Problems ja offenbar sehr genau. Lass uns doch daran teilhaben.

OP #7434441
Lesenswert?

Rolf M. schrieb:

Ich verstehe das Problem noch nicht so ganz. Du versetzt die Platte per hdparm -Y in den Standby, und das funktioniert auch wie gewünscht. Wenn du aber den Status abfragst, fährt sie dadurch wieder hoch.

Nein, im Normalfall wird die Platte nach t=120 (10 min) ohne Aktivität in den Standby versetzt. Lt. Abfrage ist sie auch im Standby. Real hört man sie aber laufen, was aber nicht so sein dürfte. Erst der Aufruf "hdparm -Y" bringt die Festplatte dazu wirklich runter zu fahren.

OP #7445304
Lesenswert?

So, das wars, keinen Bock mehr Ich hab gegen das 1. Gesetz (never Change ...) verstoßen und wurde sofort abgestraft. Hab vor ein paar Tagen eine andere Platte eingebaut, dann alle Daten kopiert und alles getestet. Heute dachte ich mir: 'Prima, jetzt noch die alte Platte ausbauen und dann Wochenende'. Also Server runtergefahren, alte Festplatte abstöpseln, ausbauen. Aber der Power-Stecker vom Board war im Weg, also abziehen, Platte raus, anstecken. Deckel drauf und ... nix geht mehr. CPU-Lüfter läuft, kein Piep, kein Monitor, keine Bios, keine Tastatur. Okay, alles noch mal zurück, abstecken, wieder dran, RAM raus und wieder rein, alles ab, anderes Netzteil, CMOS-Batterie raus, CPU raus und wieder rein, Power-Stecker nachlöten, nix, kein Erfolg. Irgendwann fing der Piepser regelmäßig zu piepen an. Das hat er am Anfang nicht gemacht, erst später, nach etlichen Power-on-off und nachdem ich ihm mal länger an hatte, ca. 5min. Resultat: kein Server mehr kotz. Genau das gleiche Board gibt's nicht mehr zu kaufen, jedenfalls hab ich auf die Schnelle nichts gefunden. Deshalb jetzt hier die Frage nach einer Empfehlung für ein alternatives Board mit Prozessor, da ich hier leider nicht weiß was es geext hat, Board oder Prozessor. Das alte war ein Fujitsu D3401-B2 Intel Q150 So.1151 Dual mit einem Pentium G4400 2 x 3,3GHz.

Also was würdet ihr empfehlen für die folgenden Voraussetzungen:

  • möglichst geringer Strombedarf
  • Linux, nur Konsole, keine hohe Performance nötig
  • M.2 Socket
  • 4 x SATA
  • DVI-Anschluß (ich will den Monitor echt nicht wieder abbauen)
  • hab ich schon erwähnt: wenig Strombedarf. (der alte hatte incl. Platten 26W)

Danke für Empfehlungen.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren