Re: Narrowing down problem source
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
Reply to: