Samsung HD204UI vs. WD WD20EARS

[Sinkx1]

Aufgrund der aktuellen Meldungen zur Samsung F4 bezüglich des S.M.A.R.T Problems wollte ich die Diskussion zu den aktuellen 2TB Patten nochmal anregen und die Infos sammeln. Ich plane immer noch eine Aufrüstung auf 2x 2TB da mir die 2x 500GB zu knapp sind. Ich denke dass einige Andere hier auch zwischen zwei Stühlen stehen und sich nicht so recht entscheiden wollen. Ich führe hier auch nur die Unterschiede auf. Einen schönen Test und Vergleich gibt es auch auf Tomshardware zu lesen woher auch einige Daten stammen. Link http://www.tomshardware.de/2TB-spinpoint-f4eg-hd204ui-wd20ears,testberichte-240660.html

Samsung F4EG (HD204UI)

- Preis z.Z. ca. 73€
- Cache 32MB
- sequenzielle Lese-Transferrate von 140,4 MB/s
- Zugriffszeit lesen/schreiben 15,7 ms / 16,5 ms
- Leerlaufleistung 3,7W

Was mir noch nicht ganz klar ist bei den Bezeichnungen ob das hier stimmt ?

HD204UI - "512B"
HD204UI/Z4 - "4K Sector"
HD204UI/UZ4 - "4K Sector with 512B Emulation"

Hier nochmal der Link zum S.M.A.R.T Problem http://www.heise.de/newsticker/meld...en-auf-Samsung-Festplatte-Update-1143120.html

Wie es scheint wird es bald ein Firmwareupdate seitens Samsung geben um das Problem zu beseitigen.

WD Caviar Green WD20EARS

- Preis z.Z. ca. 83€
- Cache 64MB
- sequenzielle Lese-Transferrate von 127,8 MB/s
- Zugriffszeit lesen/schreiben 15,5 ms/ 21,3 ms
- Leerlaufleistung 2,6W

Problem mit schnell wachsenden LLC-Wert (LoadCycleCount), also schlafen legen der Platte und parken der Schreib-/Leseköpfe.

Hier gibt es zwei Möglichkeiten:

1. Mit dem LLC leben und sich nicht darum kümmern
2. Mit diversen Tools die Zeit bis zum schlafen legen zu vergößern

Zum aktuellen Zeitpunkt kann ich mich nicht wirklich für eine der beiden Platten entscheiden.

 

[Super-Grobi]

Jo, wunderbar. Es gab auf dem c't Link von Dir ein Update, wonach das kein Problem durch/mit Smart ist, sondern mit dem ATA Identify-Device Befehl...

Grüße
Jörg

[c't Zitat / Auszug]
Mittlerweile hat sich herausgestellt, dass nicht etwa SMART-Abfragen die Festplatte zu dem Fehler veranlassen, sondern der ATA-Befehl "IDENTIFY DEVICE". Diesen sendet nicht nur der Aufruf "smartmontools -a" an die Platte, sondern unter Linux etwa auch "hdparm -I". ..................................

Ohh, das wächst sich ja langsam zu einer mittleren Katastrophe für Samsung aus
"Laut Samsung haben auch die Laufwerke HD323HJ, HD502HJ, HD503HI, HD103SJ, HD105SI und HD153WI aus der Baureihe F3 manchmal Probleme mit den SATA-6G-tauglichen Ports der SB850."

 

[Sinkx1]

Für die Leute die bereits die F4 im Einsatz haben wird es mit dem Update bestimmt nicht einfach ?! Mit der Syno aufspielen wird wahrscheinlich nicht gehen oder ?

Sollte das Problem damit wirklich geschichte sein wäre das schonmal nicht schlecht, aber auch ein Grund mehr noch nicht sofort zu kaufen.

Ich weiß das natürlich jeder gerne zu seinem Favorite plädiert aber evtl. kann man die Sache zwischen den Platten möglichst Objektiv gestalten. Wie gesagt ist bei mir noch keine aus dem Rennen.

 

[spacelord_de]

Das Problem tritt nur bei bestimmten S-ATA Kontrollern auf und smartmontools unter Windows (http://www.heise.de/ct/meldung/SMART-Tool-beschaedigt-Daten-auf-Samsung-Festplatte-Update-1143120.html. Demnach für die Syno kein Problem. Nutze selbst diese Platten ohne Probleme.

 

[HarryPotter]

Demnach für die Syno kein Problem.

Faslch. Synology hat die Probleme nachvollziehen können und die Platte deshalb von den Kompatibilitätslisten entfernt

 

[spacelord_de]

Prima, hab nun genauer gelesen SamsungF4EGBadBlocks Probleme konnten wohl bei einem x86 PC nachvollzogen werden. Link. Vorsichtshalber von der Liste genommen. Ich kann nur sagen das ich keine Probleme habe, aber ausschließen lässt es sich wohl nicht. Habe auch die betroffene Firmware

smartctl --all /dev/sda 
smartctl version 5.38 [armle-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device: SAMSUNG HD204UI Version: 1AQ1

 

[janus]

Prima, hab nun genauer gelesen SamsungF4EGBadBlocks Probleme konnten wohl bei einem x86 PC nachvollzogen werden. Link. Vorsichtshalber von der Liste genommen. Ich kann nur sagen das ich keine Probleme habe, aber ausschließen lässt es sich wohl nicht. Habe auch die betroffene Firmware

smartctl --all /dev/sda 
smartctl version 5.38 [armle-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device: SAMSUNG HD204UI Version: 1AQ1

Diese Firmware habe ich auch und ich werde ein Firmware Update schön eine Platte nach der anderen einspielen. So es denn bald ein solches Update gibt. Samsung ist nicht gerade für schnelligkeit bekannt, wenn es um Support geht.

Also DS runter, Platte raus, Firmware drauf, Platte rein und DS wieder rauf fahren. Das ganze 5 Mal nacheinander und hoffentlich ohne Datenverlust. Auf ein Recovery habe ich gar keinen Bock.

Gruß

Janus

 

[randfee]

ist ja klasse, frage mich, was der Synology Support den Leuten sagt, die diese Platten verbaut haben, sie standen ja schließlich mal auf der "compatible-list". Müssen die nun "irgendwie" anders Backupen und ihre Platten updaten.. ^^. Ist ja geil.

 

[Super-Grobi]

Moin,

Bei dem Backupen bin ich gerade bei 2.3 TByte.
Ok, war eh geplant alle Fenrndsehaufzeichnungen & Ripps auch mal zu Backupen. Insofern war das jetzt nur der Tritt in den Allerwertesten um es auch mal zu machen.

Das wirklich üble an dem Ding ist ja wohl dass man den Fehler als solches überhaupt nicht mitbekommt da einfach mal stumpf Daten nicht geschrieben werden, also plötzlich alte Daten in der Datei rum stehen. (Außer es passiert in der Verzeichnis Struktur, da fällt es dann ja schneller auf, aber auch mit verheerenderen Folgen)

Nur wenn man ein Raid hat, könnte man bei einem Block zu Block Vergleich feststellen, dass es einen Unterschied gibt.

Frage Raid 1 Verhalten: Würde beim Lesen eines solchen Raid1-Blocks die FW der DS Alarm schlagen und die Differenz anzeigen? Oder liest sie aus Performance Gründen ohne Vergleich nur einen der Blöcke?

Frage Raid 5 Verhalten: Kann mir kaum vorstellen, dass die den XOR Block beim Lesen testen, dann müssten sie den Sektor ja auf allen Platten des Raids lesen und dann vergleichen. Beim Hardware Raid Controller ja, da wird es so sein, aber wie sieht es bei der DS aus?

Grüße
Jörg

 

[Super-Grobi]

Moinsen, weiß das hier wirklich keiner?

Frage Raid 1 Verhalten: Würde beim Lesen eines solchen Raid1-Blocks die FW der DS Alarm schlagen und die Differenz anzeigen? Oder liest sie aus Performance Gründen ohne Vergleich nur einen der Blöcke?

Frage Raid 5 Verhalten: Kann mir kaum vorstellen, dass die den XOR Block beim Lesen testen, dann müssten sie den Sektor ja auf allen Platten des Raids lesen und dann vergleichen. Beim Hardware Raid Controller ja, da wird es so sein, aber wie sieht es bei der DS aus?

Oder horcht die DS "nur" darauf das eine Platte echte Fehler meldet (Sektor Read / Position , komplett Tot, etc... ) um dann Alarm zu geben?

Grüüüße

 

[Super-Grobi]

hmmpf, irgendwie hätte ich gedacht, dass das der eine oder andere weiß...
na gut, ich werde dann mal den Synology Support befragen und das Ergebnis hier poschdn...
Grüße

 

[itari]

Es kein ganz einfacher Sachverhalt, weil das Softraid unter Linux (md) eher davon ausgeht, dass man inkorrekte Schreiboperationen vom Plattencontroller signalisiert bekommt und man von daher weiß, welche Platte nun das Problem macht. Dass eine Platte Daten entgegen nimmt und damit rückmeldet, es ist alles ok, aber nicht wirklich schreibt, ist also ein echtes Problem. Wenn nun noch einmal Korrektur gelesen würde und z.B. bei einem RAID1 zwischen den beiden Platten eine Differenz auftritt ohne dass eine (Schreib-)fehlermeldung einen Defekt gemeldet hat - z.B. einen Paritätsfehler, dann ist kaum einfach zu entscheiden, welche Platte denn nun die gültigen Daten vorhält und damit zum Original avancieren kann. Die Problematik würde auch noch für ein 3er RAID1 gelten genauso wie für eine RAID5 oder 6.

hier ist noch Lesestoff, der das ein wenig beleuchtet

Itari

 

[Super-Grobi]

Moin itari,

dann ist kaum einfach zu entscheiden, welche Platte denn nun die gültigen

ist richtig, dass könnte in diesen Fällen wenn überhaupt nur der Nutzer selber sagen. Viel wichtiger wäre ja aber die Information als solche, dass es zu Unterschieden gekommen ist.
Denn nur dann weiß ich das
- ich diese Daten jetzt nicht mehr backupen sollte
- ich jetzt mein Backup benötige
- ich evtl ein Problem mit Hard oder Software habe.
Und kann entsprechende Maßnahmen ergreifen.

Wenn ich das nicht weiß, renne ich ja einfach nur in mein Unglück rein, und vernichte/verunreine u.Umständen auch noch mein Backup mit den defekten Daten.

Deshalb die Frage,
- ob dieser check bei jedem lesen gemacht wird? Meine Vermutung bisher, nein.
- ob es ein Tool gibt, mit dem ich diesen Check separat machen kann. Deinem Link nach könnte "md" so etwas machen.

Grüße

Jörg

 

[itari]

Deshalb die Frage,
- ob dieser check bei jedem lesen gemacht wird? Meine Vermutung bisher, nein.
- ob es ein Tool gibt, mit dem ich diesen Check separat machen kann. Deinem Link nach könnte "md" so etwas machen.

Ich vermute auch, dass beim Lesen kein Check gemacht wird. Es wird zufällig wechseld von beiden Platten bei einem 2plattigen RAID1 gelesen, weil ja angenommen wird, dass beide Platten identische Daten enthalten, denn sie sind beim Schreiben ja als gültig empfunden worden.

Es kann sein, dass es eine Option in dem mdadm-Tool gibt, mit dem man einen Konsistenzprüfunge durchführen kann. Das meiste was da prüft, behandelt allerdings die Metadaten.

Man könnte das RAID aufbrechen und zu 2 BASIS-Laufwerken degradieren und dann einen Dateivergleich starten auf Linux-Ebene z.B. mit einem diff oder anderen ausgefeilteren Tools (md5-compare oder sowas). Aber dann könnte man auch einen rsync-Trockenlauf* machen zwischen dem Original und dem Backup und du kannst dann anhand des Datums überprüfen, ob eine Änderung durch eine ganz normale Datenänderung entstanden ist oder ob ein Speicherfehler vorliegt. Der rsync ist eigentlich das beste Werkzeug, was sowas erledigen könnte.

Itari

*Trockenlauf [-n dry-run] ist eine Option, wo nur geschaut wird, was bei einem Sync anstehen würde, wo aber nicht wirkich gesynct wird.

 

[janus]

Ich vermute auch, dass beim Lesen kein Check gemacht wird. Es wird zufällig wechseld von beiden Platten bei einem 2plattigen RAID1 gelesen, weil ja angenommen wird, dass beide Platten identische Daten enthalten, denn sie sind beim Schreiben ja als gültig empfunden worden.

Es kann sein, dass es eine Option in dem mdadm-Tool gibt, mit dem man einen Konsistenzprüfunge durchführen kann. Das meiste was da prüft, behandelt allerdings die Metadaten.

Man könnte das RAID aufbrechen und zu 2 BASIS-Laufwerken degradieren und dann einen Dateivergleich starten auf Linux-Ebene z.B. mit einem diff oder anderen ausgefeilteren Tools (md5-compare oder sowas). Aber dann könnte man auch einen rsync-Trockenlauf* machen zwischen dem Original und dem Backup und du kannst dann anhand des Datums überprüfen, ob eine Änderung durch eine ganz normale Datenänderung entstanden ist oder ob ein Speicherfehler vorliegt. Der rsync ist eigentlich das beste Werkzeug, was sowas erledigen könnte.

Itari

*Trockenlauf [-n dry-run] ist eine Option, wo nur geschaut wird, was bei einem Sync anstehen würde, wo aber nicht wirkich gesynct wird.

Moin,
wer sicher sein will, dass die Daten sauber auf der Platte stehen, sollte nicht nach dem RAID schielen, sondern ein Dateisystem einsetzen, welches Checksummen über alle Dateien bildet. ZFS kann sowas z.B. ;-)

Mit ext3 oder ext4 dürften die Karten eher schlecht stehen, vor allem, da Linux eher in Richtung Performance, als auf Datensicherheit gebaut ist. Da war kürzlich ein interessanter Artikel auf c0t0d0s0.org. Im Moment bin ich aber nicht bereit ein OpenSolaris auf die DS zu installieren, ganz abgesehen davon: Hat das schon mal jemand probiert?

Bleibt für Linux also erst mal nur die Hoffnung, auf z.B. das btrfs, da dieses ja mit dem Ziel gebaut wird, ZFS Konkurenz zu machen. Ok, es gibt für Linux ZFS für fuse, was aber IMHO keine echte Alternative ist

Gruß

Janus

 

[Super-Grobi]

Moin

wer sicher sein will, dass die Daten sauber auf der Platte stehen, sollte nicht nach dem RAID schielen, sondern ein Dateisystem einsetzen, welches Checksummen über alle Dateien bildet. ZFS kann sowas z.B. ;-)

Oh, spannender Ansatz. Frage mich jetzt nur, wann die denn geprüft werden würde... Es müsste ja wieder die komplette Datei gelesen werden um den Test zu machen.

naja, aber wie es ausschaut, hätte man mit Raid derzeit auf der DS mit der von itari genannten Option

*Trockenlauf [-n dry-run] ist eine Option, wo nur geschaut wird, was bei einem Sync anstehen würde, wo aber nicht wirkich gesynct wird.

zumindest eine Möglichkeit zu prüfen ob alles noch ok ist. Das finde ich doch schon mal beruhigend.
Weniger beruhigend finde ich, dass ich kein Raid 1 habe, sondern nur ein Backup
( war ja wieder klar, frei dem Motto nach: Ich brauch kein Sex mehr, mich f*ckt das Leben jeden Tag )

Grüße
Jörg ( der morgen seine Platten patched )

 

[janus]

Moin



Oh, spannender Ansatz. Frage mich jetzt nur, wann die denn geprüft werden würde... Es müsste ja wieder die komplette Datei gelesen werden um den Test zu machen.

naja, aber wie es ausschaut, hätte man mit Raid derzeit auf der DS mit der von itari genannten Option

zumindest eine Möglichkeit zu prüfen ob alles noch ok ist. Das finde ich doch schon mal beruhigend.
Weniger beruhigend finde ich, dass ich kein Raid 1 habe, sondern nur ein Backup
( war ja wieder klar, frei dem Motto nach: Ich brauch kein Sex mehr, mich f*ckt das Leben jeden Tag )

Grüße
Jörg ( der morgen seine Platten patched )

Moin,
ZFS erkennt natürlich auch erst wieder beim Lesen, ob die Daten korrupt sind. Da ZFS aber Redundant speichert, kann ZFS die Fehler entsprechend korrigieren, solange, wie gehabt, nicht zu viele Fehler auftreten.
Mit dem scrub commando kann ZFS auch dazu gebracht werden das Filesystem einmal komplett durch zu prüfen.

Ok, kleiner Exkurs in die Solaris Welt, wo ZFS mittlerweile das Default Dateisystem ist.
Bisher kenne ich nur ein kleineres Problem bei ZFS bei der Fragmentierung, ansonsten schiele ich immer wieder mal neidisch in Richtung Solaris. ZFS ist eine richtig Coole Sache, nur so als Stichworte:
Snapshots
Checksum
Copy on Write
Zetabytes Filesystem uvm.

Gruß

Janus

 

[itari]

Gibt es denn Hinweise, dass ZFS auch bei dem Samsung-Platten-Problem die Flügel hängen lässt oder kann das mit solchen Controllerfehlern besser umgehen?

Itari

 

[janus]

Gibt es denn Hinweise, dass ZFS auch bei dem Samsung-Platten-Problem die Flügel hängen lässt oder kann das mit solchen Controllerfehlern besser umgehen?

Itari

Tja,
was heisst den in dem Zusammenhang "Die Flügel hängen lassen".

ZFS würde zumindest feststellen, dass die Daten korrupt sind, was ein normales RAID + Filesystem einfach nicht leistet, da dieses sich auf die Hardware verlässt.

Da beim ZFS auch noch Redundanz im Spiel ist und ZFS dies nutzt, um die Daten ggf. doch noch ordentlich lesen zu können, wäre die Chance gross, dass die Daten noch gelesen werden könnten. Wenn die Korruption über die Redundanz hinaus geht, hat man eh keine Chance mehr.

Gruß

Janus

 

[itari]

was heisst den in dem Zusammenhang "Die Flügel hängen lassen"

So wie hier diskutiert: der Plattencontroller meldet Schreibvollzug, aber die Daten landen im Nirwana.

Itari