War eigentlich davon ausgegangen, dass dd sowieso beim ersten fehlerhaften Sektor abbrechen würde... allerdings läufts jetzt schon ziemlich lange durch, ohne Abbruch. Melde mich in Kürze wieder mit Erfolgs- oder Misserfolgsmeldung.
edit: stelle fest, dass 'dd' seltsamerweise plötzlich sehr langsam wird. Während die ersten paar Dutzend GB noch rasend schnell gingen, hat er inzwischen einige Minuten pro GB. Scheint als würde der Speed sehr massiv eingebrochen sein. Aber die Speed-Abfrage (mittels -USR1) liefert wohl nur die (sinkenden) Durchschnittswerte und gibt somit keinen Aufschluss über den aktuellen Speed.
edit2: yay... hab mal kurz den aktuellen speed überschlagen und damit die restdauer ausgerechnet... dann dauerts ja nur noch knapp 4 Tage bis die Platte gewiped ist -.-
(was insofern passend ist, dass die Rettung mittels ddrescue auch 4 Tage gedauert hat :p - aber ich hatte gehofft, zumindest fürs löschen gäbs ne bessere Methode... muss doch möglich sein, die defekten Sektoren einfach zu überspringen und den Rest mit Full-Speed zu wipen?!)
edit3: Gemäss einer Website soll man dd mit 'conv=noerror' ausführen, damit es defekte Sektoren ignoriert. Habs getestet. Resultat: dd bricht bereits nach einer Sekunde mit input/output error ab...
edit4: Nach einem Neustart des Systems & dem Befehl aus Edit3 tut sich nun was. Allerdings von Beginn an 'nur' mit 18 MB/s... (anstatt gut 90 wie ohne conv=noerror)... aber falls sich dieser Speed wenigstens durchhalten lässt, wär das schonmal was.
Allerdings bin ich mal wieder etwas verwundert über das seltsame Verhalten des Systems...
edit5: Okay... auch mit conv=noerror beendet sich dd irgendwann mit einem Input/Output Error (obwohl gemäss Anleitungen genau dies damit verhindert werden soll...)
Hat noch irgend jemand eine Idee?
edit6: 'sudo dd if/dev/zero of=/dev/sdc conv=noerror,sync' endet ebenfalls mit einem Input/Output Error, obwohl es ja eigentlich Fehler ignorieren sollte.
Es muss doch einen Weg geben?!
edit7: Ich teste jetzt 'sudo badblocks -svw /dev/sdc' in der Hoffnung, dass ein Programm welches eine HDD in schreibender Weise auf Badblocks testen kann, seinen check nicht bereits beim ersten Badblock abbrechen wird... wenn dass nicht klappt, muss ich wohl oder übel zu 'hdparm --security-erase' greiffen, aber das soll ja nicht gerade eine empfohlene Methode sein...
edit8: badblocks hat auch begonnen 'durchzudrehen' (bzw. es hat plötzlich sein logging-verhalten geändert das Tempo total verlangsamt und lustigerweise reagiert es auch nach einem neustart nun anders als zuvor.... darauf habe ich hdparm probiert, doch auch dies schlägt fehl, weil ich dank einem input/output error nichtmal ein security-password setzen kann...
Echt ganz grosses Kino.
Und hier Monologe zu führen bin ich ja gewohnt - aber ich fürchte am Ende wird diesmal nichtmal eine Lösung rausspringen, für irgendjemand der nach mir mal das selbe Problem hat und auf diesen Thread stossen sollte...