views:

777

answers:

7

I have backups of files archived in optical media (CDs and DVDs). These all have par2 recovery files, stored on separate media. Even in cases where there are no par2 files, minor errors when reading on one optical drive can be read fine on another drive.

The thing is, when reading faulty media, the read time is very, very long, because devices tend to retry multiple times.

The question is: how can I control the number of retries (ie set to no retries or only one try)? Some system call? A library I can download? Do I have to work on the SCSI layer?

The question is mainly about Linux, but any Win32 pointers will be more than welcome too.

A: 

dd(1) is your friend.

dd if=/dev/cdrom of=image bs=2352 conv=noerror,notrunc

The drive may still retry a bit, but I don't think you'll get any better without modifying firmware.

Daniel Papasian
I don't think this will reduce the number of retries by the optical drive. noerror simply means that dd, instead of aborting, will continue after failing to read a block. I think that the failure to read a block will propagate to dd only after the optical drive has tried everything it could.
Alexander
In addition to Alexander's comment, your suggestion of bs=2352 implies you think that reading the "raw" device allows you to read all ECC data regardless of the sectors being Mode 1 (typical for CD-ROM discs)
ΤΖΩΤΖΙΟΥ
Alexander, the thing is that most applications, when they fail a read(), will either abort or, more likely, retry (perhaps because it's thinking the media will become available later). So while you aren't reducing the number of reads per attempt, you are reducing the number of attempts.
Daniel Papasian
Good point, @Daniel. I wonder though whether standard tools, say, <code>cp</code> do retry on the application level or not.Actually, if it were possible to use <code>dd</code> to read a Mode-1 disc as though it were a Mode-2 one, it could work. But I suspect the hardware deals with this.
Alexander
+1  A: 

While checking whether hdparm could modify the number of retries (doesn't seem so), I thought that, depending on the type of error, lowering the CD-ROM speed could potentially reduce the number of read errors, which could actually increase the average read speed. However, if some sectors are completely unreadable, then even lowering the CD-ROM speed won't help.

Alexander
A: 

Since dd was suggested, I should note that I know of the existence and have used sg_dd, but my question was not about commands (1) or (1m), but about system calls (2) or libraries (3).

EDIT

Another linux command-line utility that is of help, is sdparm. The following flag seems to disable hardware retries:

sudo sdparm --set=RRC=0 /dev/sr0

where /dev/sr0 is the device for the optical drive in my case.

ΤΖΩΤΖΙΟΥ
I didn't know about sg_dd. Thanks for mentioning it!
Alexander
The package, at least on Gentoo, is called sg3_utils.
ΤΖΩΤΖΙΟΥ
If the question was intended to be "not about commands (1) or (1m)", you should say so *in the question*.
Andrew Medico
This is a site for programmers, so this is a programming question. I gave examples for the pointers I want: system call, library I can download or SCSI layer.
ΤΖΩΤΖΙΟΥ
+1  A: 

Since you are asking about driver level access, you should look into SCSI commands, or perhaps an ASPI like API. On windows VSO software (developers of blindread/blindwrite below) have developed a much better API, Patin-Couffin, that provides locked low level access:

http://en.wikipedia.org/wiki/Patin-Couffin

That might get you started. However, at the end of the day, the drive is interfaced with SCSI commands, even if it's actually USB, SATA, ATA, IDE, or otherwise. You might also look up terms related to ATAPI, which was one of the first specifications for this CD-ROM SCSI layer interface.

I'd be surprised if you couldn't find a suitable linux library or example of dealing with the lower level commands using the above search terms and concepts.


Older answer:

Blindread/blindwrite was developed in the heyday of cd-rom protection schemes often using intentionally bad sectors or error information to verify the original CD.

It will allow you to set a whole slew of parameters, including retries. Keep in mind that the CD-ROM drive itself determines how many times to retry, and I'm not sure that this is settable via software for many (most?) CD-ROM drives.

You can copy the disk to ISO format, ignoring the errors, and then use ISO utilities to read the data.

Adam Davis
+7  A: 

man readom, a program that comes with cdrecord:

   -noerror
          Do not abort if the high level error checking in readom found an
          uncorrectable error in the data stream.

   -nocorr
          Switch  the  drive  into  a mode where it ignores read errors in
          data sectors that are a result of uncorrectable  ECC/EDC  errors
          before reading.  If readom completes, the error recovery mode of
          the drive is switched back to the remembered old mode.
   ...

   retries=#
          Set the retry count for high level retries in readom to #.   The
          default  is  to do 128 retries which may be too much if you like
          to read a CD with many unreadable sectors.
derobert
Yes, readom source code seems to be the closest to what I was seeking. I'll wait a little more before awarding the bounty. Thanks.
ΤΖΩΤΖΙΟΥ
A: 

Take a look at the ASPI interface. Available on both windows and linux.

bang
+4  A: 

The best tool avaliable is dd_rhelp. Just

dd_rhelp /dev/cdrecorder /home/myself/DVD.img

,take a cup of tea and watch the nice graphics.

The dd_rhelp rpm package info:

dd_rhelp uses ddrescue on your entire disc, and attempts to gather the maximum valid data before trying for ages on badsectors. If you leave dd_rhelp work for infinite time, it has a similar effect as a simple dd_rescue. But because you may not have this infinite time, dd_rhelp jumps over bad sectors and rescue valid data. In the long run, it parses all your device with dd_rescue.

You can Ctrl-C it whenever you want, and rerun-it at will, dd_rhelp resumes the job as it depends on the log files dd_rescue creates. In addition, progress is shown in an ASCII picture of your device being rescued.

I've used it a lot myself and Is very, very realiable.

You can install it from DAG to Red Hat like distributions.

motobói