HDD defekt : nur lesen über MemoryStream funktioniert ..Hä?

[helgew]

Hallo liebe Forengemeinde,

Nachdem sich gerade meine WD16 00JD 00GBB0 verabschiedet (160GB SATA-Platte), habe ich schon ein paar Dinge versucht, um noch ein paar der seit dem letzten Backup hinzugekommenen Daten zu retten. Mittlerweile habe ich auch board, sata-controller und Zielfestplatte getauscht, es kann also nurnoch an der defekten HDD liegen, wenn man annimmt, dass Windows keinen Mumpitz macht.

Nun meine Frage:
Wieso um alles in der Welt sind mit Sicherungstools, xcopy oder via blockweisem Kopieren über filestreams alle Dateien zu 10-300ppm mit falschen Bytes durchsetzt, wenn es sich um jpg-Dateien handelt, diese aber mit Bildbearbeitungsprogrammen darstellbar?
Daraufhin habe ich in paar Zeilen code gebastelt, die die Datei zunächst ins RAM laden, um sie dann am Zielort zu speichern. Was unterscheidet den Zugriff eines Filestreams von dem eines memorystreams?


ps. hat jemand einen Vorschlag, wie ich große Dateien kopieren soll? Ich werde versuchen, 256MB-Blöcke zu kopieren und diese dann am Ziel zusammenzusetzen.

[sirius]

Eigentlich ist für so etwas immer diskdump unter linux eine leicht Erfolg versprechende Variante. Du musst nur eine gleich große (und gleich aufgebaute) backuppartition haben.

[Blup]

Nach deiner Fehlerbeschreibung ist möglicherweise ist eine Speicherbank in der Steuerelektronik der Festplatte defekt.
Ich würde eine baugleiche Platte (nach Möglichkeit aus der selben Serie) besorgen und die Platine tauschen.

[helgew]

Danke für den Tip, ich werde mich auf jedenfall nach einer baugleichen Festplatte umschauen. Das mit dem Speicher ist mir auch schon in den Sinn gekommen, ich habe auch schon das Bitmuster finden können, das überall reingestempelt wird. Ich verstehe jedoch noch immer nicht, wieso die Verwendung des Festplattencaches derart vom Lesemodus abhängt.

[sirius]

Wie lädst du die Datei in den RAM?

Filestream ist bedeutend anders als Memorystream. Memorystream greift ganz einfach via Pointer auf den RAM, genauer auf den virtuellen Arbeitsspeicher, der natürlich auch auf der Platte sein kann.

[helgew]

Hallo,

zunächst habe ich keine sonderliche Lust, eine Linux Live CD zu basteln, mit der ich auch NTFS-Partitionen mounten kann, aber danke für den Hinweis.

Meine Frage begründet sich in eben der Tatsache, dass ich nicht genau verstehe, worin nun der Unterschied besteht, ob ich Daten in einen Puffer lade und von dort aus weiterschreibe. Mein erster Versuch war das Kopieren von Dateien in 2MB-Blöcken, was jedoch nicht funktionierte.

Zitat:

Quelle öffnen (Filestream)
Ziel öffnen (Filestream)

2MB Block lesen
2MB Block schreiben
2MB Block lesen
2MB Block schreiben
.
.
.

Ziel schließen
Quelle schließen

dies produzierte in gleichem Maße Fehler wie "DirSync" und xcopy.


Folgender Algorithmus funktioniert hingegen:

für kleine Dateien:

Zitat:

Memorystream erzeugen
von Quelle laden
als Ziel speichern
Stream freigeben

für große Dateien:

Zitat:

Quelle öffnen (Filestream)
Position suchen
128MB Block lesen
Quelle schließen

Ziel öffnen
ans Ende gehen
128MB Block schreiben
Ziel schließen

wiederholen, bis alles kopiert ist (der letzte Puffer ist nicht ganz gefüllt)

Lesen ist weiterhin kein Problem, ich kann mir nur nicht erklären, wieso Schreibzugriffe auf andere HDDs nicht funktionieren, während das handle auf die defekte Festplatte noch gültig ist.

Die einzige Lösung in diesem Fall kann also nur sein, den Lese/Schreibmodus der HDD derart zu begrenzen, dass der betreffende Speicherbereich des controllers nicht mehr benutzt wird, da kann mir auch kein Linux helfen. Nun denn, Vorschläge zur Güte? (Sorry, mit der Geduld geht es langsam zuende)

[sirius]

Zitat von helgew:

zunächst habe ich keine sonderliche Lust, eine Linux Live CD zu basteln, mit der ich auch NTFS-Partitionen mounten kann, aber danke für den Hinweis.

Du musst die Partition ja nicht lesend interpretieren müssen, du brauchst sie ja nur verstehen. Anders gesagt, es ist völlig egal welches Filesystem da drauf ist, das interessiert dich zu keinem Zeitpunkt.

Ob du damit allerdings deinen Controler "überlisten" kannst, weis ich nicht.

[helgew]

Bisher arbeite ich iterativ daran mit ein paar Stückchen code...
mein Vergleichstool spuckt eine Batchdatei zum Abgleich aus, in der auch die Fehler protokolliert werden. Fehlende Dateien werden zunächst auf gut Glück kopiert, was bei kleineren Dateien meist funktioniert. Startet man die Batchdatei, werden die defekten Dateien nach oben beschriebenem Algorithmus geflickt. Dies hat ein paarmal nicht funktioniert, weil auch Dateisystemfehler am Ziellaufwerk aufgetreten sind (mitkopiert oder schlimmeres). Daraufhin wurde chkdsk auf der Zielplatte ausgeführt und das ganze wiederholt. Mittlerweile habe ich bei 3 von 5 Partitionen alle rettbaren Dateien kopiert, es sind noch 5-200 Dateien pro Partition irreparabel beschädigt.
Das ganze hätte ich mir etwas eleganter vorgestellt, da es jedesmal 300GB sind und "nur mal checkdisk laufen lassen" 1-2h dauert.

Bisher weiß auch niemand, welcher Modus für derlei Probleme empfänglich ist und welcher nicht. Gibt es keinen Transfermodus, der ohne Puffer arbeitet?

[hathor]

Nur mal so am Rande bemerkt:

Wenn ich den Verdacht habe, dass eine HDD defekt ist, werde ich versuchen, eine vollständige 1:1-Kopie zu machen, z.B. mit

http://www.acer-userforum.de/tutoria...tml#post137684

http://www.miray.de/de/products/sat.hdclone.html#free

Die Ziel-HDD darf grösser sein und können beide als USB-HDD betrieben werden.

Alles andere, z.B. Checkdsk, macht nur noch mehr Fehler und stresst eine HDD unnötig.

Auf der Ziel-HDD kann man dann mit diversen Tools "in Ruhe" versuchen, die Files wieder herzustellen.