[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Thomas Schmitt wrote:

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

This does not match the behavior on my oldish system

First suspicios thing:
  # blockdev --getra /dev/hdg
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.

There is a possibility that loss would be up to a full read size, I think. That's because if you ask for N and get an error, the loss will be N, I don't think the read tells how much it read without error, nor would most programs use that if they got the information.

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 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

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.

Have you tried setting both to zero and asking to read just the number of blocks in the ISO filesystem?
Only skillful reading helps.
(I am so proud of my reading skills 8-))

I wonder if this lack of problems here is because I'm using DVD burners, not CD-only. I have upgraded every production system to DVD, just to avoid "can't reads that here" delays.
Have a nice day :)

You seem to have raised legitimate doubts about the behavior of DVD vs. CD units, as well as known issues on kernel versions. And I think code was being added to 2.6.23, or is queued for 2.6.24 to return a short read and no error in just this situation. I'll have to see if I can find the reference.

bill davidsen <davidsen@tmr.com>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

Reply to: