Neue Seagate 10TB-HDD Kapzitätsfehler?

Los

Los

Enthusiast
Thread Starter
Mitglied seit
13.09.2009
Beiträge
784
Ort
Rheinland-Pfalz!
Hi zusammen,

habe leider ein merkwürdiges Problem mit meiner neuen ST10000NM0016 (steckt in einem externen USB3.0-Gehäuse - habe leider aktuell nur einen Laptop zum Testen):
Bevor ich sie mittels LUKS verschlüsseln wollte, sollte natürlich erst einmal geprüft werden, dass die HDD auch i.O. ist. Dazu habe ich h2testw (unter Win7) gestartet und leider zweimal das gleiche Ergebnis bekommen:

Habe nach dem ersten Lauf die Partitionstabelle gelöscht gehabt und komplett neu initialisiert + neue Partition (NTFS) angelegt.
SMART-Werte:


Leider bin ich mir unsicher, was ich mit diesem Ergebnis nun anfangen soll - aktuell lasse ich chkdsk drüberlaufen, was aber entsprechend lange dauern wird (hochgerechnet 11 Stunden)...

Hoffe, jemand kann mir weiterhelfen,
Los
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
einfach die bereits geschriebenen Daten überprüfen.
Die Fehlermelodung ist völlig normal, wenn man NTFS Partitionen in voller Grösse prüft, da die Metadaten des Dateisystems auch Platz brauchen (und zwar mehr als ursprünglich bei der Programmierung angenommen).
Einfach ein paar Megabyte weniger prüfen lassen
 
Bist du dir sicher? Windows zeigt folgende Daten an:

10000294965248 Bytes entsprechen 9537024 Megabytes - das ist die gleiche Größe, die auch h2testw ausgibt...
 
Danke für den Link. Das Problem ist, dass der Thread-Ersteller vom letzten MiB spricht werden - bei mir fehlen 38MiB...

Hab jetzt was Neues gestartet - h2benchw. Nach dem Löschen der Partitionen testet das die ganze Platte - mal gucken, was dabei rauskommt.
 
Der h2test ist eigentlilch für Flash-Speicher gedacht (vor allem USB-Sticks und SD-Karten), weil es da schon lange viel B-E-T-R-U-G gab, und es ein Leichtes für die ******** ist, in den Eigeschaften des Gerätes eine andere Speichergröße anzugeben, als tatsächlich vorhanden ist. Daraufhin testet h2, aber das ist bei Festplatten einfach nicht angebracht.
Geeignet wäre z.B. der Error-Test von HDTune.
 
Ok, akzeptiert.
Lasse h2benchw jetzt mal fertiglaufen und wenn da auch ein negatives Ergebnis bei rum kommt, melde ich mich nochmals.
 
Elmario schrieb:
Der h2test ist eigentlilch für Flash-Speicher gedacht (vor allem USB-Sticks und SD-Karten), weil es da schon lange viel B-E-T-R-U-G gab, und es ein Leichtes für die ******** ist, in den Eigeschaften des Gerätes eine andere Speichergröße anzugeben, als tatsächlich vorhanden ist. Daraufhin testet h2, aber das ist bei Festplatten einfach nicht angebracht.
Geeignet wäre z.B. der Error-Test von HDTune.
Zum Vergrößern anklicken....
Nö!
Der Error Test von HD-Tune ist ggü. h2wtest ein "Alibitest", da HD-Tune nicht schreibt. Die leeren Sektoren einer neuen HDD zu lesen ist so sinnvoll wie ein Kropf.
Zum zweiten ist h2wtest auch eine gute Möglichkeit für ein Burn-In, da hier Platte einmal "komplett" beschrieben und gelesen wird. Wenn die Smartwerte danach OK sind, dann kann man der Platte Daten anvertrauen, da eine gute Chance besteht, daß die Platte die Einlaufphase überstanden hat.
Es gibt Leute die die Burn-In Phase deutlich länger gestalten.
Ich z.B. mache zusätzlich einen Full Read Bench und einen Full Write Bench mit HD-Tune, um zu schauen, ob es Auffälligkeiten im Verlauf gibt.

- - - Updated - - -

Los schrieb:
Ok, akzeptiert.
Lasse h2benchw jetzt mal fertiglaufen und wenn da auch ein negatives Ergebnis bei rum kommt, melde ich mich nochmals.
Zum Vergrößern anklicken....

Das ist primär ein Benchmark.
 
Die Daten welche von der Festplatte gelesen werden wurde ja nunmal zuvor darauf geschrieben. Und wenn es nicht der Test selbst war, das macht keinen Unterschied.
 
@digi-Quick: h2benchw beinhaltet einen Integritäts-Check, und den lasse ich aktuell laufen. Wenn damit verifiziert wird, dass sich jeder Sektor beschreiben lässt und die geschriebenen Daten nicht korrupt sind, bin ich fürs Erste zufrieden. Dann erfolgt vorbereitend auf die Verschlüsselung mit LUKS die abermalige vollständige Beschreibung der Sektoren mit Zufallsdaten, wo ggf. noch Fehler bemerkt würden (weil sich gewisse Sektoren nicht beschreiben lassen).
Und dann muss ich wohl oder übel darauf vertrauen können, dass es klappt.

Oder habt ihr eine bessere Idee? Die HDD soll als Server-Datengrab dienen - habe eine Server-SSD, auf der die Datenbanken und das OS liegen, und die auf die HDD ihre primären Backups ablegt. Die HDD sichere ich dann von Hand auf 2 separat einzurichtende eineiige Drillinge der HDD.
 
Das nutzt Dir aber bei Fehladressierungen nichts, denn soweit ich weiß kann eben h2benchw nicht feststellen, ob die Daten auch auf dem LBA geschrieben wurden, auf dem sie stehen sollten. Prüfe Deine Testdaten von h2testw, die sollten fehlerfrei geprüft werden können, auch wenn Du vergessen hast ein paar Hundert MB auszuwählen als vorgeschlagen wird. NTFS legen eben seine Metadaten in verstecken Dateien (fangen mit $ an und können im Explorer gar nicht angezeigt werden) ab die spare angelegt werden, also mit der Nutzung wachsen und heise hat damals unterschätzt wie groß die bei großen Volumen werden.

Bei den S.M.A.R.T. Werte sind nur die High-Fly Wirtes auffällig, aber bei so viele G-Sensor Auslösungen wundern die mich nicht, steht da ein Bass in der Nähe oder sowas?
 
Was ich mich frage: Warum fragt hier niemand welches Gehäuse er nutzt ?. 10TB sind schon eine ordentliche Marke!.
 
@SystemX: Das Gehäuse hatte ich durchaus als Grund im Hinterkopf - bisher hat es bei 1TB-, 2TB-, 4TB-, 6TB- und 8TB-HDDs zwar keine Probleme bereitet, aber man kann ja nie wissen.
Um das aber auszuschließen, ist gerade h2benchw ne gute Idee - da keine Partitionen (auch kein MBR/GPT) benötigt werden, beschreibt es alle Sektoren der HDD. Und wenn die beschrieben und gelesen werden können, sollte das Gehäuse kein Problem darstellen, oder?

@Holt: Ok, einverstanden. Was S.M.A.R.T.-Werte angeht: Hier ist eine stark befahrene Straße direkt neben dem Haus. Allerdings liegt die HDD extra auf einem Schaumstoffkissen, um das zu minimieren :-[

h2testw ist zwar gut, um die Sektoren zu prüfen, die es beschreiben kann, aber über den Rest erhalte ich keine Auskunft...
 
Zuletzt bearbeitet:
Mein Problem ist, dass h2testw 9537024 MiB Kapazität ausweist, die es testen möchte - was exakt die von Win7 angegebene verfügbare Kapazität ist.
Es müsste also nicht nur h2testw die verfügbare Kapazität falsch berechnen, sondern auch Win7. Das deutet darauf hin, dass der Fehler, den timbr gefunden und auf den mich Digi-Quick hingewiesen hat, mittlerweile (zumindest teilweise) behoben ist.
Positiv ist, dass h2benchw mittlerweile die vollständigen 9,1 TiB beschrieben hat:


Somit bleiben 38MB, die von h2testw nicht korrekt gestestet werden können, was ich jetzt auf andere Art und Weise prüfen muss.

Habe den Titel des Threads mal angepasst.

- - - Updated - - -

@Holt: Aber h2testw prüft doch auch nicht, wo diese Daten liegen, oder sehe ich das falsch?
 
Zuletzt bearbeitet:
Was ist nun dein eigentliches Problem? Hast du Angst, dass die Daten auf der Platte nicht sicher sind?
Ich meine, bisher hast du gut gezeigt, dass Festplattenhersteller bei der Umrechnung den Faktor 1000 und nicht 1024 nehmen und ein Dateisystem wie NTFS einen gewissen Overhead hat. Das ist jetzt beides erst mal nicht besorgniserregend, oder übersehe ich etwas?

Liebe Grüße
 
Ich wollte mit dem Test eigentlich sicher verneinen, dass die HDD einen Defekt hat. Aber das ist mir mit h2testw nicht gelungen. Oder stehe ich wirklich auf dem Schlauch?
 
Teste sie doch einfach mit HD_Sentinel_4.71.

Ist ein super Tool und du hast sämtliche Informationen über die Festplatte(n).
 
Los schrieb:
Ich wollte mit dem Test eigentlich sicher verneinen, dass die HDD einen Defekt hat. Aber das ist mir mit h2testw nicht gelungen. Oder stehe ich wirklich auf dem Schlauch?
Zum Vergrößern anklicken....
Ja, tust du, denn wie schon erwähnt wurde, ist diese Diskrepanz normal!
Auch dass es beim verlinkten User ein anderer Wert ist normal, denn die Größe des MBR ist von der Plattengröße abhängig.
 
Los schrieb:
Mein Problem ist, dass h2testw 9537024 MiB Kapazität ausweist
Zum Vergrößern anklicken....
Nicht ganz richtig.
h2testw meldet den (beim Start) noch freien Speicherplatz.
Während des Beschreibens durch h2testw wachsen aber die NTFS-Verwaltungsdateien (z.B. die MFT) und belegen Platz, den h2testw dann nicht mehr beschreiben kann, in Deinem Fall als die ca. 381 MB.

Los schrieb:
Aber h2testw prüft doch auch nicht, wo diese Daten liegen, oder sehe ich das falsch?
Zum Vergrößern anklicken....
Siehst Du falsch, h2testw schreibt in den Testdateien Informationen darüber, an welcher Adresse die Dateien liegen. Aufgrund dieser Informationen ist es h2testw überhaupt erst möglich festzustellen, welche Menge an (Flash-)Speicher fehlerhaft ist oder ob Speicher mehrfach unter anderen Adressen angesprochen wird, wie es bei Fake-Flash der Fall ist oder durch fehlerhafte/alte Treiber bei Festplatten auftreten kann.

Lass zum Test gerne mal einen kleinen USB-Stick (oder eine kleine Partition) mit mehr als 1 GB Kapazität mit h2testw prüfen, so dass h2testw mindestens 2 Testdateien anlegt.
Wenn der Test fehlerfrei war, bei 2 der Testdateien die Dateinamen tauschen (z.B. 1.h2w -> 2.h2w und 2.h2w -> 1.h2w) und den Lesetest erneut machen. h2testw sollte dann melden, dass der von den beiden Dateien belegte Speicher überschrieben wurde.
 
Zuletzt bearbeitet:
Los, eigentlich wurde ja schon alles mehrfach erklärt, aber da Du vielleicht immer noch auf dem Schlauch stehst: Das "Problem" bei h2testw ist, dass es auf Dateiebene arbeitet und normale Dateien anlegt. Dies führt dazu, dass die Metadaten von NTFS, die eben in Dateien abgelegt werden die mit der Nutzung des Filesystems wachsen (können) und dies auch machen, weshalb sie am Ende mehr Platz belegen als am Anfang. Wenn also am Anfang noch 9537405MB frei waren und dann doch nur 9537024MB geschrieben werden konnten, dann liegt es einfach daran, dass diese Metadateien die restlichen 381MB in der Zwischenzeit belegt haben um die Informationen für die rund 9000 h2w Testdateien zu verwalten.

Dies berücksichtigt h2testw schon und schlägt bei NTFS formatierten Datenträgern auch schon gleich vor weniger zu testen als zu Beginn an freier Kapazität gemeldet wird, nur ist es eben ein altes Programm aus einer Zeit als so große Volumen nicht üblich waren und wurde für USB Sticks und Speicherkarten entwickelt, also eher kleine Datenträger und daher hat man bei der Berechnung eben zu wenig abgezogen. Deshalb sollte man von Hand noch ein paar Hundert MB bis 1GB weniger eintragen als vorgeschlagen wird, damit eben dieser Fehler (Datenträger schneller als erwartet voll!) nicht passiert, denn dafür kann die HDD nichts und das ist auch nicht ihre Schuld, die kennt keine Partitionen, Verzeichnisse, Dateien oder auch Metadateien von NTFS, die stellt nur Speicherplatz zu Verfügung und der bleibt immer gleich groß. Man kann trotzdem die geschriebene Daten hinterher testen und es sollte auch keinen Fehler geben.

Der Nachteil von h2testw auf Filesystemeben zu arbeiten hat aber auch den Vorteil, dass man damit umfassender alles testet als bei Low-Level Tests und diese Low-Level Test erkennen eben in aller Regel nicht, ob sie wirklich die Adressen auslesen die sie beschrieben haben, die schauen nur ob da Fehlermeldungen von der Platte kommen, aber wenn es z.B. eine Adressierungsfehler gibt und 2TiB adressiert werden, dann werden sie eben die erste 2TiB 4 bis 5 mal testen und die restlichen 7,8TB gar nicht prüfen, wenn es keinen HW Fehler gibt, scheint dann alles in Ordnung, aber sobald jenseits der 2TiB Grenze geschrieben wird, ist Dir (meist der mehr oder weniger totale) Datenverlust sicher. Das Problem würde h2testw aber erkennen, denn es legt bei den Testdaten auch ab, wo diese stehen müssen und wenn es dann beim Lesen feststellt, dass die Daten woanders stehen müsste als an dem Ort von dem sie tatsächlich gelesen wurden, dann gibt es da eine Fehlermeldung beim Prüfen! Fehlermeldungen, vor allem solche über falsche Bits, können bei h2testw übrigens auch aufgrund von RAM Fehlern kommen!
 
Und warum sollte man sie mit FAT32 formatieren? man kann auch NTFS nehmen und einfach ein paar Dutzend MB weniger wählen als vorgeschlagen wird oder die Fehlermeldung am Ender des Schreibvorgangs ignorieren, der besagt ja nur, dass am Ende wegen der wachsenden Metadateien des Filesystems eben weniger Platz verfügbar war als anfangs von h2testw erwartet. Das ist ja nicht Schuld der Platte und damit kein Hinweis auf ein Problem der Platte.
 
Genau darum geht's, wenn man auf Nummer sicher gehen will. Ansonsten würde ich h2testw erst garnicht machen.
Ist zwar unwahrscheinlich, dass ausgerechnet bei den paar MB was defekt ist, aber ich will keine halben Sachen.
 
Also mal ehrlich, wie viel Prozent bleibt denn ungetestet? 100MB sind viel weniger als 1% von 10TB und wenn Du mit einer über 99%igen Testabdeckung nicht leben kannst, dann lesen ein Unterverzeichnis an und schreibe oder noch einmal die paar MB rein die frei sind. Es geht doch auch weniger um den vollständigen Test der Oberfläche, den macht der Hersteller im Werk, also um die Adressierung (also darum Probleme mit Treibern und ggf. USB-Gehäusen zu erkennen) und die ganze Mechanik. 100% kannst Du auch mit FAT nicht abdecken, da bei FAT beim Formatieren ein fester Bereich für die Metadaten angelegt wird und den kannst Du nur zu 100% ausnutzen, wenn Du auch bei der Zahl der Dateien ans Limit gehst.
 
Zuletzt bearbeitet:
Auch wenns es hier schon mehr oder weniger deutlich gesagt wurde ich möchte nochmals hervorheben das h2testw für das was du willst nicht geignet ist da nicht die gesamte Festplatte geprüft wird.

Ich empfehle folgendes Tool: https://en.wikipedia.org/wiki/Badblocks wobei es da auch bestimmt viele andere gibt die genau das gleiche machen.

Dieses Tool schreibt und verifiziert und wieder ob korrekt gelesen wurde.
Damit kannst du zuverlässig ermitteln ob die Festplatte defekte Sektoren oder sonstige Probleme hat.

Man kann jetzt mit Erbsenzählerei kommen aber mein Motto ist da eher wenn schon dann richtig.
 
Zuletzt bearbeitet:
Da ist mir das "viel weniger als" entfallen.
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh