Bist Du Dir beim Selbsttest sicher?
Ziemlich. Bei den "Seatools for Windows" z. B. steht, dass alle einfachen Tests nur lesend zugreifen und die anderen schreiben nur defekte bzw. schwächelnde Sektoren (bei USB-Platten) neu bzw. versuchen es.
Andernfalls würde ein kompletter Scan vollständiges Read/Rewrite bedeuten - es müssten alle Sektoren gelesen und gleich wieder geschrieben werden. Das dauert länger und bremst nur bei sinnvollen Blockgrößen wenig. (Im Fehlerfall wäre dann mal ein Block weg ...)
Weiter hinten steht, das bei den langen Tests "alle Sektoren der Festplatte ausgeLESEN werden" und "... Test wird scheitern ... ... wenn ein fehlerhafter Sektor auf einer internen Platte gefunden wird"
So wie ich es kenne, muss man erst mit speziellen Tools versuchen einzelne, schwächelnde Sektoren zu "reparieren". S.M.A.R.T lässt sich bei defekten Sektoren auch Zeit und tauscht erst ziemlich spät - nach mehreren Schreibversuchen.
Um defekte Sektoren zu eliminieren, gibt es in den Hersteller-Tools ja die Optionen für Zero-Fill/LLF - damit soll man die HDD "retten", wenn man defekte Sektoren findet, ehe man RMA in Erwägung zieht.
(so hatte ich das bei hutil/ESTool gelesen/verstanden)
Macht die HDD gleich den Schreibtest mit, wären solche Anweisungen für den Kunden überflüssig.
Fakt bleibt, dass der HDD-Test keinerlei Probleme durch Anwendungen oder Treiber-Bugs aufdeckt. Er testet nur den Zustand der Platte.
Von 100MiB bis 2TiB-1MiB - liegt somit komplett innerhalb des 32 Bit Adressraums Von 2TiB+1MiB bis Ende - liegt somit komplett außerhalb des 32 Bit Adressraums Von 1MiB bis 99 MiB - liegt somit komplett innerhalb des 32 Bit Adressraums und steht bei reiner 32Bit Adressierung an der selben Stelle wie 2. (Das müsste schon sichergestellt werden!)
Der Knackpunkt ist, dass Partition 2 eben real IM 32 Bit Adressraum liegt, wenn der 2,2 TB-Bug besteht - auch wenn die eigentlich außerhalb eingetragen ist.
Beim Zugriff von Systemen die nur mit 32Bit Adressieren würde nun beim Versuch Partition 2 zu lesen der Inhalt dieser Partition erscheinen.
Es dürfte dann Fehlermeldungen hageln, da NTFS gekennzeichnet ist (Partitions-ID) und das Dateisystem real FAT32, außerdem passen die Partitonsgrößen nicht (2 TB nominal und gelesenes Dateisystem über 100 MB).
Zum "blinden" Testen, ob der Bug vorliegt, ist die Methode aber geeignet: Partition 1 vorne von 1 MiB bis z. B. 100 MiB, dann Partition 2 von 100 MiB bis 2,2 TiB und Partition 3 exakt im gleichen Abstand von 2 hoch 32 wie Partition 1 von Sektor 0. Gleiches Dateisystem auf Partition 1 und 3.
Schreibt man nun auf Partition 3, landen die Daten auf Partition 1. Allerdings müsste man da exakt nach Sektoradressen partitionieren und das ist auch eher für Fortgeschrittene.
Man könnte ein Test-Image mit den Partitionen erstellen, dass auf der Testplatte zurückgespielt wird => noch ein paar Dateien auf Partition 3 kopieren und schauen, ob auf Partition 1 etwas gelandet ist. Das wäre noch für Anfänger vertretbar. Leider habe ich keine leere 4 TB HDD mehr zum Testen, sind alle schon in Backupplatten umgewandelt. Sonst hätte ich es schon mal versucht ...
In der Praxis ist es aber gar nicht so kompliziert, die Größte Gefahr besteht, wenn man unter Windows - mit verbugtem Treiber - die Partitionen erstellt und nicht Crossover testet.
Normalerweise merkt man schnell, das eine Partition als "RAW" angezeigt wird oder es beim Zugriff Fehlermeldungen hagelt. Dann muss aber schleunigst nach der Ursache gesucht werden.