Thomas Schmitt wrote:
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.
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?
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 <[EMAIL PROTECTED]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
