Sven Anders wrote:
>
> On Sun, 11 Jul 1999, Douglas Gilbert wrote:
>
> > If you wish to take a closer look at what is happening then perhaps you
> > could download the utilities tarball at: http://www.torque.net/sg
> >
> > You will need to have the sg device driver available (either built into
> > the kernel or as a module). Then try: sg_readcap /dev/sr0 [or /dev/sr1]
> >
> > to see what your block size is and the address of the last block. For
> > example, if your block size is 2048 and the last block address is
> > 332529 then try: sg_dd2048 if=/dev/sgc of=/dev/null skip=332529 count=1
> >
> > This utility is just like "dd" but will report any SCSI error directly
> > to you (and bypasses the cdrom code). This example assumes the sg device
> > /dev/sgc is the same as the cdrom driver you wish to test. Sg devices
> > are allocated in the same number and order seen in 'cat /proc/scsi/scsi'.
> >
> > Such a test works ok for CDRs burnt on my Yamaha 4416S by cdrecord.
> > However a friend who uses similar hardware and NT to burn CDRs always
> > seems to get an error on the last block just as you seem to. However
> > those CDRs give a "L-EC UNCORRECTABLE ERROR" error which is different
> > from your report.
> >
> > Also the position of the error you have reported is awfully close to
> > the 650 MB limit for a CDR.
>
> Hello !
>
> Thanks for the answers.
>
> I tried the sg utilities and attached some of your suggested outputs.
> As your can see, it works perfectly on my CD-Writer. The Problem is,
> that the read with dd from the normal CD device (drivers) does not work.
> Here it fails to read a whole 7 sectors, not only 2 (which seems to be
> normal and would be taken care of the CD device driver!
> This means a serious data loss.
>
> The read with sg_dd2048 works perfectly.
>
> When I try to access the last file on the CD normal with mounting the
> CD all works perfectly. This seems really strange to me, because I
> thought, that the file-system reads via the normal CD device drivers
> which dd uses too.
>
> Any further ideas ?!
Sven,
I posed a question about this on the
[EMAIL PROTECTED] newsgroup and found out
some interesting information.
It seems that iso9660 CDs often have 2 or more
"run out" blocks which may or may not be visible
when a READ CAPACITY is done. There is a utility
that comes with xcdroast called 'isosize' which
I think delves into the iso9660 table of contents
to work out the length. This is probably a more
accurate figure than the READ CAPACITY that sg_dd2048
and dd most likely use.
Further, both sg_dd2048 and dd (I guess) read multiple
blocks at a time to improve performance. So if there
is an IO error on one of the latter blocks in a
multi-block sequence, then you won't see any of the
blocks from that sequence in your output file.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
