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
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.
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.
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.
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...
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.
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.
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.
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.
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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.