[Achtung] Besitzer einer WD Festplatte achtet auf eure Load/Unload Zyklen! (betrifft nicht nur WD Green!)

[Goonie]

Threads zusammengefügt.

 

[buddabrod]

(Wobei ich immer glaubte unter Windows bleibt das erhalten nach einem reboot.. mhh.)

Die Einstellung sollte nicht mal den Standby überleben.

 

[Evilandi666]

Ja war auch ein Schreibfehler .. meinte natürlich ich dachte unter Linux bleibt das gesetzt ...

sry

@Goonie danke!

Edit: Heut ist der Wurm drin .. jetzt auch noch nen Doppelpost rausgelassen.. :crying:

 

[Enervis]

Du meinst weil es "konstanter" ist im Sinne von "bleibt nach dem reboot erhalten"?

Ja ist es in der Hinsicht. Aber es ist nicht so ganz klar welche HDDs von dem WDIdle3 unterstützt werden - das muss man eben probieren.

2.5" Festplatten werden laut der WD-Seite ja überhaupt nicht unterstützt, trotzdem hat es mit meiner WD3200BEVT einwandfrei funktioniert

Ausser das die Änderung eben permanent ist, sehe ich noch den Vorteil, dass man mit dieser Lösung ja wirklich nur das Timeout hochsetzt und die anderen Power Management Einstellungen unverändert bleiben. Mit hdparm konnte ich bei meiner WD nur das APM ingesamt heruntersetzen, das Timeout alleine ließ sich nicht verändern. Dadurch wurde die Platte um mehrere Grad wärmer und der Stromverbrauch hat sich erhöht - was bei dem mit WDIdle erhöhten Timeout nicht in dem Maße passiert.

 

[go4hl80ve]

die load-cycles sollte man insbesondere bei platten im dauerbetrieb beobachten.

ich hab mir gegen märz 2010 ein nas zusammengebaut, welche 24/7 läuft.
drin stecken 2x WD500BEVT (2,5" sata, 500gb, blue serie) und 1x WD15EARS (3,5", 1,5TB, green serie).

da die 500er platten im host-raid1 liefen, konnte ich nicht auf die smart-parameter zugreifen (betraf alle platten).
wird schon gehen, dacht ich mir...

als die große 3,5" platte vor zwei wochen anfing zu spinnen, hab ich mir mal die mühe gemacht nachzugucken.
Fazit:
power_on_time: 5820h, also ca. 240 Tage
power_on_cycles: 38

soweit, so gut - das hatten sie alle gemeinsam.
dann die überraschung:

load_cycle_count
wd15ears: 155'000 (platte soll 300'000 aushalten)
1. wd500bevt: 560'000 (soll bis etwa 600'000 halten)
2- wd500bevt: 1'500'000 !!!!

interessanterweise hatten sie alle die gleiche zeit beim timer gesetzt (8sec).
es würde mich allerdings schon interessieren, warum die eine platte im raid1 dann 3x so oft parken durfte.

fazit:
timer deaktiviert; und immer mal wieder smartmontools anwerfen.

das timer deaktivieren scheint aber nachhaltig zu helfen. seit dem sind keine load-cycles dazugekommen

 

[Evilandi666]

Läuft da Linux als OS?

(Das betrifft ja fast nur Linuxuser)

Mit der 1500k Platte haste aber Glück - mehr als das doppelte als sie halten sollte.

Krass.

 

[moronoxyd]

load_cycle_count
2- wd500bevt: 1'500'000 !!!!

Mit der 1500k Platte haste aber Glück - mehr als das doppelte als sie halten sollte.

Die Angaben der Hersteller, auf wie viele Loadcycles oder ähnliches Platten ausgelegt sind, bedeuten nicht, daß die Platten kurz nach Erreichen der Zahl in die Brüche gehen.
Das sind nur grobe Richtwerte, die unter dem liegen, was die Hersteller in ihren internen Tests als sicheren Wert ermittelt haben.
Die Hersteller sind da eher konservativ, zu optimistische Werte könnten ihnen auf die Füße fallen, wenn doch mal was schief geht.

Die meisten Platten werden deutlich mehr aushalten. (Siehe meine Samsung im X60, die bei 6,3 Mio. Cycles ist.)

 

[go4hl80ve]

Läuft da Linux als OS?

(Das betrifft ja fast nur Linuxuser)

Mit der 1500k Platte haste aber Glück - mehr als das doppelte als sie halten sollte.

Krass.

dank MSDNAA hab ich ohnehin kostenlosen zugriff auf die meisten (teuren) M$-produkte.
daher lief erst server 2008, jetzt server 2008 R2.

ich dachte ja ursprünglich auch, dass nur linux-server von dem load-cycle problem betroffen sein sollten, aber dem war wohl doch nicht so...

den 2,5" platten traue ich noch einiges zu. im notebook werden die ja auch nicht geschont.
immerhin ließen sich von der 3,5" noch die meisten daten retten. allem anschein nach waren nur einzelne sektoren betroffen.

ob das dann direkt mit den load-cycles zusammenhängt lässt sich natürlich schwer sagen.

EDIT:
achso, jetzt verrichtet übrigens eine 2TB Seagate Barracuda LP 5900.12 2000GB, SATA II (ST32000542AS) den dienst der WD15EARS.
im hdtune-benchmark hat die allerdings auch ein paar unschöne einbrüche...

 

[Evilandi666]

load_cycle_count
2- wd500bevt: 1'500'000 !!!!

Mit der 1500k Platte haste aber Glück - mehr als das doppelte als sie halten sollte.

Die Angaben der Hersteller, auf wie viele Loadcycles oder ähnliches Platten ausgelegt sind, bedeuten nicht, daß die Platten kurz nach Erreichen der Zahl in die Brüche gehen.
Das sind nur grobe Richtwerte, die unter dem liegen, was die Hersteller in ihren internen Tests als sicheren Wert ermittelt haben.
Die Hersteller sind da eher konservativ, zu optimistische Werte könnten ihnen auf die Füße fallen, wenn doch mal was schief geht.

Die meisten Platten werden deutlich mehr aushalten. (Siehe meine Samsung im X60, die bei 6,3 Mio. Cycles ist.)

Ich glaube generell sind Hersteller nicht uninteressiert daran dass die Festplatten knapp ausserhalb der Spezifikation verrecken, sei es kurz nach Ende der Garantie oder durch knappe Überschreitung sonstiger "mindest"-Anforderungen.

 

[moronoxyd]

Das Problem ist, daß es bei Werte wie den Loadcycles nicht einen Punkt gibt, ab dem die Ausfallquote sprunghaft ansteigt, sondern daß einfach mit steigendem Wert die Ausfallquote steigt.
Und mehr noch als viele Ausfälle nach der Garantiezeit ist den Herstellern wichtig, daß die Ausfälle IN der Garantiezeit niedrig bleiben. Denn das kostet Geld.

Ob ein Kunde nochmal bei mir kauft, wenn mein Produkt kurz nach Ende der Garantiezeit die Grätsche macht, steht in den Sternen.
Daß der Kunde sich aber an mich wendet, wenn das Gerät kurz vor Ende aufgibt, das ist sehr viel wahrscheinlicher.

 

[buddabrod]

Warum benutzt ihr eigentlich "hdpam -S"? das setzt doch nur das Spindown Timeout und sollte nichts an den Loadcycles ändern.


Habe bei meiner WD5000BEVT auch mal wdidle3 angewendet. Ergebnis: Timeout auf max. 30 Sekunden einstellbar, ändert aber garnichts am realen Verhalten. Komplett deaktivieren bringt auch nichts. Außer, dass die HDD ab und an ein *sehr* seltsames Geräusch macht.

 

[Enervis]

Warum benutzt ihr eigentlich "hdpam -S"? das setzt doch nur das Spindown Timeout und sollte nichts an den Loadcycles ändern.

Na, die load cycles werden doch durch den ständigen spin down verursacht, dachte ich!?

Habe bei meiner WD5000BEVT auch mal wdidle3 angewendet. Ergebnis: Timeout auf max. 30 Sekunden einstellbar, ändert aber garnichts am realen Verhalten. Komplett deaktivieren bringt auch nichts. Außer, dass die HDD ab und an ein *sehr* seltsames Geräusch macht.

Bei mir hat die Einstellung auf 30 Sekunden das Problem gelöst, die durch den Idle Timer verursachten load cycles und die damit verbundenen Geräusche treten nicht mehr auf

 

[buddabrod]

Dann kann meine HDD das wohl nicht...

Load_cycle und Spindown sind zwei paar Schuhe.
hdparm -B ändert den APM Level, welcher auch gleichzeitig die Load_cycle Häufigkeit erhöht/reduziert. Wenn der APM Level über 127 gesetzt wird, ist kein Spindown mehr möglich, bei 254/255 gibts keine Load_cycles mehr. Und auch keine Stromsparfunktion.

Spindown Timeout wird per hdparm -S eingestellt, und zwar in Sekunden. Wenn der APM_Level es zulässt, schaltet sich die Platte nach der eingestellten Zeit ohne HDD-Zugriff ab.

Und nur hdparm -B ändert was am Stromverbrauch, sofern die Platte nicht abgeschaltet hat

 

[Enervis]

Und nur hdparm -B ändert was am Stromverbrauch, sofern die Platte nicht abgeschaltet hat

Genau, deswegen gefällt mir die Lösung mit WDIdle ja auch viel besser.

Ich verstehe allerdings immer noch nicht, warum das idle timeout nichts mit den load cycles zu tun haben sollte: wenn das timeout erreicht ist, idled die Platte und parkt die Köpfe. Dabei wird jeweils ein load cycle verursacht. Höheres timeout bedeutet also weniger load cycles. Bei mir funktioniert das jedenfalls bestens...

 

[buddabrod]

Dagegen habe ich doch nichts gesagt. Aber per hdparm kann man kein idle-timeout setzen. Nur Spindown timeout. Und das verhindert keine load_cycles.

 

[Evilandi666]

Doch tut es bei einigen seltsamerweise.

Frag mich jetzt nicht warum, keine Ahnung, Wird aber oft benutzt/vorgeschlagen in dem Zusammenhang.

Man Page sagt ja

"-S set standby (spindown) timeout"

Vllt. ist das falsch oder trifft bei WDs nicht zu ?

Keine Ahnung

 

[buddabrod]

Bei meiner WD macht es genau das, was es soll: Es steuert die Zeit, bis die Platte sich in den standby versetzt.

 

[Evilandi666]

Keine Ahnung, ich habs mir nicht ausgedacht, bei mir am Notebook setzte sich damit der Counter jedenfalls nicht mehr höher soweit ich mich erinner.

Nächste Runde werd ich mit WDIdle machen

 

[Evilandi666]

Sooo hab das Eingangspost mal umstrukturiert und den ganzen hdparm quatsch als veraltet markiert, hier und da was geändert!

Falls jemand noch eine schöne Windows Anleitung schreiben will die ich via copy & paste dort einfügen darf, wäre das super!

 

[vbtricks]

Naja, die bestehende Beschreibung reicht doch vollkommen. Mit der Kombination aus dem verlinkten Tutorial zum Erstellen des USB-Sticks und den Aufrufkonventionen für wdidle3.exe ist das doch kein Ding

Jetzt warte ich nur noch drauf, dass meine Schwester sich endlich dazu durchringt, die WD20EARS zu kaufen. Dann könnte ich den eh schon vorbereiteten USB-Stick gleich nochmal einsetzen .