Hi Jeffrey, On 24.04.2016 10:29, Jeffrey Carlson wrote: > > The short answer is: yes! Your progress will be lost. > > > This is disappointing! You mean my progress since the last write to > the logfile, or all nearly 500GB of progress?
The progress until the last successful written logfile will be saved. Looking at the status you posted you will lose about 1300MB of data. See, the logfile is used to mark unsuccessful reads. Everything that was read OK is saved to the image file. The sectors that are not OK will also be written, but in the form of a placeholder. They will be filled with rescued data in the repeated attempts after the first try. 497982MB (497GB) of your data is rescued. The rest is marked to be retried. Ddrescue automatically determines the positions that are not OK and retries them in the second run. TBH, 497GB of successfully rescued data is quite good. I don't know what files you are trying to recover, but it is better to try rescuing data from this image file than retrying to rescue 100% of the drive! Whatever is causing the failure of your drive, might have destroyed some data. If it is a physical error it is hard to rescue from those sectors. The real problem is, the longer you are running ddrescue, it is more likely that the drive will fail completely. (Physically!) No matter if the logfile is writeable or not. > > I believe that the drive to which the file was output was temporarily > unplugged (it was jostled, at least, near to when the error occurred), > and this caused the error. I cannot be sure of anything though. When I > replugged it, it came back as read-only. When I fixed that, there also > wasn't very much space. I freed up 2 GB on the partition by lessening > the proportion reserved for root using tune2fs. > > The "Read-only file system error" persisted through all this. It was > true the first time, but all the tools I know indicate it is no longer > true. I believe you might've fixed the read-only problem. > > > My guess is that the output drive somehow failed and messed up either > file permissions or simply messed up the whole logfile. > > > Maybe. There's nothing obviously wrong in the last-written version of > the logfile, which I've since backed up. That's good. But as per your "ls" query and inspection of the logfile, it is OK and should be writeable. (even though it is not necessary to be executable) > > > Just to make sure. When did the write error occur? After which > command? > I guess the first one worked fine, but did not work after that? > > > The error only occurred after the last one. I haven't tried running > again since the error. I've kept my computer on, in one place, for a > few days now, hoping to find a way to write this logfile without > pressing Q+ENTER. It will not work. You need to stop the process. If the logfile is not writable since you started ddrescue it is no use at all. The errors that were recovered after the last rescue attempt will be lost, no matter what you will do, assuming the logfile is still not writeable. > > I'm hesitant to do this because I'm worried I haven't communicated > clearly: I'm still trying to write to the other logfile; I haven't > quit yet. I'm worried that it would be bad to run two ddrescues on the > same image at once? It sounds dangerous, at least if baby3.img isn't > already useless. > Of course. Don't run two ddrescue operations! The baby3.img is NOT useless. You already have 497GB or RESCUED data! If you use the same logfile up until the point it was writable the last time, it will only retry and rescue those sectors it has marked as unreadable. If your really, really want to make sure you won't lose ANY data: Stop ddrescue, backup the baby3.img and baby3.logfile on a seperate disk (if you have a spare drive with 500GB free space!) and restart ddrescue and see if the logfile error is still there. As said above. It depends on what you want to be rescued. 497GB is a lot of data. > > It looks totally normal to me. I'd been looking at it every once in a > while (not editing it, just refreshing to see its progress and the > exciting new positions it was finding) during the last run, and it > looks more or less the same as ever. > Wait? You tried to access the logfile while ddrescue is working? And it showed you the new positions? Then the logfile is writeable? Why else would it show new positions? Now I'm confused! Or do you mean the status that ddrescue is showing while reading the drive? To be honest I'm not quite sure what you really did. I'm trying to recreate your procedure. 1. You start ddrescue with the commands you posted. Everything works OK until the last command, which then returned the error on the logfile? 2. The output drive had an i/o error and ddrescue aborted? Or did it keep on running and didn't stop? 3. You tried to fix the output disk and logfile WHILE ddrescue continued to run? > > Okay, I've gotten confused again, so I want to check to make sure I > understand before I misinterpret and do something incorrect: you are > saying that I can, WITHOUT hitting Q+ENTER to exit my current, > two-days-halted but still-active run of ddrescue, start a DIFFERENT > ddrescue with the same source drive and target image file, but writing > the logfile to a different place, without damaging the current image > file (or worse, the source drive)? > No, you should stop the current ddrescue operation. The logfile is there to resume the operation when even if you stop ddrescue. The image file you already have will not be destroyed, as long as the logfile is still there. As said above i'm not quite sure if you really stopped ddrescue ad restarted the operation after the i/o-error, because you feared that ddrescue might've to do the whole process again or overwrite rescued data. If you are still unsure, wait for Antonio to reply to your problem. Sorry, I'm getting a bit confused now i try to retrace your steps. Feel free to ask away anyway. I'm sure there is a solution for your problem. Regards. _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
