(I had accidentally sent my reply below only to Antonio. I'm resending it to the list.)
> On 10/05/2021 10:05, Malte Dehling wrote: > > Thanks a lot, Antonio, these are very valuable to have! > I've only checked a couple of them under SIMH, so it would be helpful to > know if I need to check my workflow or not. > > I think uploading them to archive.org would be a good long-term > > solution. I can take care of it if you don't have an account. > > Please do. Thanks. Will do. I'll let you know. > In other news, I polished the MAR-1989 CONOLD, which looked very bad, to > start with. Amazingly it buffed up quite nicely and then read surprisingly > well: > > [ > > $ ddrescue -r5 -v /dev/sr1 CDROM-AG-NC67A-RE-1989-03-VMS-CONOLD.iso > CDROM-AG-NC67A-RE-1989-03-VMS-CONOLD.map > GNU ddrescue 1.23 > About to copy 205199 kBytes from '/dev/sr1' to > 'CDROM-AG-NC67A-RE-1989-03-VMS-CONOLD.iso' > Starting positions: infile = 0 B, outfile = 0 B > Copy block size: 128 sectors Initial skip size: 128 sectors > Sector size: 512 Bytes > > Press Ctrl-C to interrupt > ipos: 205198 kB, non-trimmed: 0 B, current rate: 0 B/s > opos: 205198 kB, non-scraped: 0 B, average rate: 637 kB/s > non-tried: 0 B, bad-sector: 2048 B, error rate: 170 B/s > rescued: 205197 kB, bad areas: 1, run time: 5m 22s > pct rescued: 99.99%, read errors: 25, remaining time: n/a > time since last successful read: 2m 1s > Finished > ] > > > So I went ahead and tried the CONDIST from MAY-1989. That too now can be > read, although it is proving a somewhat tougher nut to crack: > > [ > > $ ddrescue -r5 -v /dev/sr1 CDROM-AG-MN36D-RE-1989-05-VMS-CONDIST.iso > CDROM-AG-MN36D-RE-1989-05-VMS-CONDIST.map > GNU ddrescue 1.23 > About to copy 623247 kBytes from '/dev/sr1' to > 'CDROM-AG-MN36D-RE-1989-05-VMS-CONDIST.iso' > Starting positions: infile = 0 B, outfile = 0 B > Copy block size: 128 sectors Initial skip size: 128 sectors > Sector size: 512 Bytes > > Press Ctrl-C to interrupt > ipos: 5919 kB, non-trimmed: 0 B, current rate: 0 B/s > opos: 5919 kB, non-scraped: 11127 kB, average rate: 14694 B/s > non-tried: 0 B, bad-sector: 2843 kB, error rate: 85 B/s > rescued: 609276 kB, bad areas: 445, run time: 11h 31m 2s > pct rescued: 97.75%, read errors: 5884, remaining time: 5d 23h 43m > time since last successful read: 2m 45s > Scraping failed blocks... (forwards) ] > > > On the plus side, that's 97.75% more data than I had before :-) but the > "remaining time" looks like it could be the rest of the week (it varies > quite a bit). > > > I think, from reading the manual, that I can use CTRL-C and restart this > again later and it will pick up where it left off using the map file. Is > this right? Very nice, this worked much better than I had expected! And you're right, you can simply CTRL-C and restart ddrescue with the same command (i.e., with the iso and map file; different options should work.) I would make a copy of the files before restarting, just in case. > Are there any other options I should consider trying? Can you try with "-b 2048 -d" for direct disc access and maybe once more with "-R" for reverse? > Another thought is that perhaps a shade more polishing might help. If I > polish the CDROM a little more and then resume the ddrescue, I think I won't > be any worse off than I am now, i.e. all existing data will still be there > and all I'll be risking is data that maybe would have eventually read before > but now may not read at all. Is that right? Successful reads are now ~20m > apart, so I suspect that the remaining data will be quite difficult to > recover. After trying the various options on the disk in its current state, I see no harm in trying this approach. With the map file, ddrescue should never overwrite already-read data. Again, I would make a copy to be safe. Cheers, Malte -- Malte Dehling <mdehling at gmail.com>
