Re: Narrowing down problem source

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

Richard Owlett wrote:
> Block count: 2284052
> Device block count: 2284064

This matches. The DVD offers more than the ISO claims.
(Just rounded up to a multiple of 16 blocks, in this case.)


> 1941504+0 records in
> 1941504+0 records out

And this is wrong.
Why does dd not obey but also not report error ?

/bin/dd is from coreutils ... google ...
  http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/dd.c;h=e64729477101f471a31adcb6582d03d2274499cf;hb=HEAD

Looks like read(2) gets an End-Of-File and returns 0.
(In line 1075, causing the iread() call in line 2127 to
 get return value 0, which causes end of the copy loop
 in line 2133, hopping to line 2230. From then on it is
 treated as successful.)
read(2) belongs to libc.
The actual work is supposed to happen in the kernel.
I will not dive in there. Not yet.


Well, if the normal i/o is swimming belly up, lets try
whether the drive is willing to hand out the blocks which
it announced to the kernel.
Replace the dd run by

  xorriso -indev /dev/sr0 \
          -check_media data_to="$FILENAME" --

xorriso will find out the size of the ISO on its own.
It will not use system function read(2) but ioctl(SG_IO)
and SCSI command READ10.
In the end it will report something like

  Media checks :        lba ,       size , quality
  Media region :          0 ,      13472 , + good
  Media region :      13472 ,         32 , + slow
  Media region :      13504 ,     958590 , + good
  ...

because it is more for finding bad spots than for retrieving
image files from medium.

Now i am curious how far it gets.
Maybe you see some SCSI error replies. If it does not yield
the expected number of bytes, please copy as much of the
last messages as possible and send them to me in private.


Have a nice day :)

Thomas