Thomas Schmitt wrote:
Hi, Bill Davidsen:blockdev --setra 0 /dev/hdcThis 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.
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.
------------------------------------------------------------------ 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 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.
Have you tried setting both to zero and asking to read just the number of blocks in the ISO filesystem?
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.Only skillful reading helps. (I am so proud of my reading skills 8-))
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