kein zugriff auf die Festplatte

[oncho]

ist aber jetzt unter windows gemacht. steht doch aberdas selbe drin, oder?

 

[Ernst@at]

Mit diesem Logfile kann er in dem letzten Lauf nicht gearbeitet haben.
Da steht der "current pos" pointer an der gleichen Stelle wie im letzten Post.
Außerdem ist die letzte Änderung dieser Datei am 23.11 um 03:59 gewesen...

Fehler in der Logfile-Zuordnung, nicht der alte wurde für diesen Lauf verwendet; er muss einen neuen angelegt haben - aber wo?

 

[oncho]

ach so, du meinst den neuen sorry.

war dort abgelegt wo auch der andere war.

 

[Ernst@at]

Naja, wenn Du früher rescue.log getippt hast und jetzt rescued.log
im ddrescue-Befehl, dann ist das ja wohl eine andere Datei.

deswegen kam auch die "nothing to do" Meldung, weil einer der Parameter verhindert, dass er bei einem weiteren Lauf den bisher im Log definierten Bereich ausweitet.
Neuer Logfile - kein Bereich eingetragen - nicht erweitert auf Plattengrenzen - nothing to do

probiers mal mit

ddrescue -B -c 1 -C -d -r 1 /dev/sdc /dev/sda /mnt/rescue.log

dann wird er auf dem alten logfile aufsetzen

 

[oncho]

ach mist.
ich hab auch schon gewundert wieso da jetzt ne zweite datei ist.
im ganzen thread haben wir von rescued gesprochen.
und gerade beim klonen geb ich nur rescue ein.
ich probiers später mal aus. sollte aber hinhauen.

Ergänzung (25. November 2010)

na also, jetzt gehts weiter.
sieht zwar genau so aus, aber unten steht splitting failed blocks.

 

[Ernst@at]

Wie lange ist ein Durchlauf jetzt gewesen? oder werkt er noch?
Prinzipiell kannst Du das jetzt mit -r 20 die ganze Nacht durchlaufen lassen und irgendwann mal abbrechen.
Dann sehen wir uns den aktuellen Stand am rescue.log an.

 

[oncho]

ist noch immer am arbeiten, glaub ich. steht immer noch splitting failed blocks.

bei time from last successful read steht aber 3,6h

ich brech mal ab. kann ich denn jetzt schon was im log sehen?

Ergänzung (26. November 2010)

bei -r 20 siehts auch so aus als ob nix passieren würde.
nur die zeit vom last successful read wird größer.

hab jetzt auch mal abgebrochen.
die rescue 20 ist vom -r 20 durchgang. hab ihn aber nur 6min laufen lassen.

 

[Ernst@at]

Viel getan hat sich bisher nicht, aber lass mal das ganze mindestens ein Mal komplett durchlaufen ohne den -r 1 Parameter, damit mal die übersprungenen Bereiche wenigstens noch übertragen werden und nur die Defektstellen übrig bleiben

ddrescue -B -c 1 -C -d /dev/sdc /dev/sda /mnt/rescue.log

 

[oncho]

habs jetzt mal gestartet.
time from last successful read: 20min

soll ichs weiter laufen lassen?

Ergänzung (27. November 2010)

jetzt schon seit ner stunde nix.

 

[Ernst@at]

Du kannst (wie in der Anleitung gezeigt) jederzeit unter Linux den gerade aktuellen Stand des Logfiles in einem anderen Fenster einsehen, Schließen/öffnen ist notwendig, um Änderungen zu sehen. Außerdem sollte ja die HDD-Activity LED doll flackern(oder Dauerlicht)
Da siehst Du ja am Pointer in den ersten Zeilen, wie weit er ist. Sind halt jeder Menge Defektstellen, die jede tausende Male zu lesen versucht werden...

 

[oncho]

also soll ichs weiter laufen lassen?
er schreibt mir half das er das letzte mal vor paar stunden zugegriffen hat.

 

[Ernst@at]

Er schreibt, dass er vor Stunden zuletzt was vernünftig lesen konnte.
Die HDD Activity LED leuchtet(blinkt) doch - oder?

 

[oncho]

wenn ich unter linux nix mache blinkt die hdd-led ab und zu kurz auf.
habs jetzt wieder mit ddrescue -B -c 1 -C -d /dev/sdc /dev/sda /mnt/rescue.log
laufen und da blinkt sie häufiger. aber kein dauerlicht oder flackern.

bei current und average rate: ist er aber trotzdem bei 0 B/s.

(was meinst du eigentlich mit dem pointer in der ersten zeile?)

 

[Ernst@at]

Da wo steht (in den ersten Zeilen, Beispiel aus einem alten Log):

# Rescue Logfile. Created by GNU ddrescue version 1.11
# current_pos  current_status
[COLOR="red"]0x08A70000[/COLOR]     +
#      pos        size  status
0x00000000  0x08A59000  +
0x08A59000  0x00000200  -
0x08A59200  0x00016E00  /
[COLOR="red"]0x08A70000  0x00000400  -[/COLOR]
0x08A70400  0x0001FE00  /
0x08A90200  0x00000400  -
0x08A90600  0x0003FE00  /
0x08AD0400  0x00000400  -
...

Dieser Wert von "current pos" ändert sich und zeigt den aktuellen Ort an, an dem er nuckelt

Vergleicht man das mit einem späteren Log (von dem -r 20 Versuch)

#      pos        size  status
0x00000000  0x08A59000  +
0x08A59000  0x00000200  -
[COLOR="SeaGreen"]0x08A59200  0x00000200  +[/COLOR]
[COLOR="Magenta"]0x08A59400  0x00026400  -[/COLOR]
[COLOR="MediumTurquoise"]0x08A7F800  0x00010A00  /[/COLOR]
0x08A90200  0x00000400  -
0x08A90600  0x0003FE00  /
0x08AD0400  0x00000400  -

so sieht man, dass er aus dem oben noch als übersprungenen Bereichen angeführten
0x08A59200 0x00016E00 /
0x08A70400 0x0001FE00 /
von 439 Sektoren

jetzt ein Sektor 0x08A59200 0x00000200 + gelesen werden konnte,
aber 306 folgende 0x08A59400 0x00026400 - nicht fehlerfrei gelesen werden konnten
und 133 Sektoren 0x08A7F800 0x00010A00 / noch nicht probiert wurden.

Also Geduld...

 

[oncho]

ah ok,

da steht jetzt
current pos: 0x08A99800
current status: /

ich kann diese position aber niergendwo finden.

hier kann ich also immer kontrollieren ob und wo was geschieht, richtig?

 

[Ernst@at]

Das liegt jetzt im beim ersten Lauf übersprungenen Bereich
0x08A90600 0x0003FE00 /
Weil der von 0x08A90600 bis 0x08E8E60 geht und 0x08A99800 dazwischen liegt.

 

[oncho]

das wird ja dann ziemlich lange dauern.
ist jetzt gerade bei 0x0B25A00. aber beim status hat sich nix geändert.

Ergänzung (29. November 2010)

ist inzwischen bei 0x08E38E00
es ändert sich aber nix beim jeweiligen status der positionen. soll ichs trotzdem laufen lassen?

 

[Ernst@at]

Ja, denn in den vorderen Bereichen der Platte ist jeder gerettete Sektor wichtig.
Damit Du den Mut nicht verlierst, hier während der Wartezeit etwas Lektüre eines ähnlichen Problemes mit viiiielen Plattenfehlern. Den gleichen Ausgang nach tagelangem zähen Ringen kann ich nicht versprechen, aber vielleicht macht's ein wenig Hoffnung...

 

[oncho]

die hoffnung stirbt zu letzt. aber es wird ja bestimmt ewig dauern, bis er da durch ist.
ich kann die ja mal nen aktuelleren log reinstellen. vielleicht siehst du ja schon ne "verbesserung".

 

[Ernst@at]

ist ja unterbrechbar, wenn man beim wiederaufsetzen keine Fehler macht.
Das dauert so lange, weil relativ große übersprungene Bereiche anscheinend großflächig defekt sind. Da könnte man erst mal in größeren Blöcken nachputzen.
Ich stell Dir dazu in der nächsten Stunde einen Vorschlag mit anderen Parametern rein
(muss erst in die Beschreibung kucken)