Re: Using dd to verify a dvd and avoid the readahead bug.

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

Hi,

Bill Davidsen:
>   blockdev --setra 0 /dev/hdc

This does not match the behavior on my oldish system
either.

First suspicios thing:
  # blockdev --getra /dev/hdg
  8
That would be 8 x 512 = 2 x 2048 bytes.
So 4 kB should be a upper limit for the loss on this drive.

But my losses of blocks with dd are often more than 32 kB.

------------------------------------------------------------------
Experiments:

I write a TAO track to CD-RW
  $ cdrskin -v dev=/dev/sg2 blank=fast padsize=0 -tao /dvdbuffer/x
which has 3041 blocks of payload and appears with -toc as
  track:   1 lba:         0 (        0) 00:02:00 adr: 1 control: 4 mode: 1
  track:lout lba:      3043 (    12172) 00:42:43 adr: 1 control: 4 mode: -1

Let us ask dd with ra=8 :

  $ dd bs=2048 if=/dev/hdg >/dev/null
  dd: reading `/dev/hdg': Input/output error
  3014+0 records in
  3014+0 records out

So there are missing 27 payload blocks = 54 kB.
That is too much, even if blockdev mistakes the unit
as 2048 rather than 512.

Next i try Bill's proposal :
  # blockdev --setra 0 /dev/hdg
  # blockdev --getra /dev/hdg
  0
I reload the tray. Just to be sure:
  # blockdev --getra /dev/hdg
  0

Banzai
  $ dd bs=2048 if=/dev/hdg >/dev/null
  dd: reading `/dev/hdg': Input/output error
  3014+0 records in
  3014+0 records out

Another drive, this time under usb-scsi:

  # blockdev --getra /dev/sr2
  32
  $ dd bs=2048 if=/dev/sr2 >/dev/null
  dd: reading `/dev/sr2': Input/output error
  3032+0 records in
  3032+0 records out

Cough. Larger readahead, less loss. Only 18 kB.

  # blockdev --setra 0 /dev/sr2
  # blockdev --getra /dev/sr2
  0
I reload the tray. Just to be sure:
  # blockdev --getra /dev/sr2
  0
  $ dd bs=2048 if=/dev/sr2 >/dev/null
  dd: reading `/dev/sr2': Input/output error
  3032+0 records in
  3032+0 records out


Let me show what can be done with the same SCSI commands
as used by the block device driver.
This is telltoc, a demo application of libburn-0.3.9, using
SCSI command 28h "READ 10".

  $ test/telltoc --drive /dev/sg2 \
                 --read_and_print 0 -1 raw:/dvdbuffer/image
  ...
  Media content: session  1  track     1 data   lba:         0    00:02:00
  Media content: session  1  leadout            lba:      3043    00:42:43
  Data         : start=0s , count=3043s , read=0s , encoding=1:'/dvdbuffer/image'
  NOTE : Last two frames of CD track unreadable. This is normal if TAO track.
  End Of Data  : start=0s , count=3043s , read=3041s                     

  $ ls -l /dvdbuffer/image
  -rw-r--r--    1 *  *    6227968 Oct  3 21:08 /dvdbuffer/image
  $ expr 6227968 - 3041 '*' 2048
  0

Exactly 3041 blocks of 2048 bytes each. None more, none less.

Now this is _my_ way to retrieve data from old CDs
out of times when 32 kB of padding were surely enough
of a sacrifice.
My 2.4 kernel already seems to need 64 kB, maybe even 128.


No hdparm helps, no blockdev helps.
Only skillful reading helps.
(I am so proud of my reading skills 8-))


Have a nice day :)

Thomas