Re: linux kernel error reading end of cd/dvd
Lourens Veen wrote:
Well, it could be a bad CD ;-) I just tried using dd on my old burner (real
SCSI), my recent burner (ATAPI+ide-scsi), and the 52x reader only (ATAPI+ide-cd)
and a Redhat 2.4.18-24.8.0 kernel, and no error on any of them. I can't try
a 2.6 kernel without rebooting, but I'll try that at work.
On Wed 8 October 2003 05:09, Rob Bogus wrote:
Volker Kuhlmann wrote:
if anyone is able to shed some more light on this kernel problem
I'd appreciate it. It's been going on for years.
When reading the whole of an iso9660 filesystem from a cd or
dvd, I often get I/O errors within the last blocks of the
This is caused by reading past the end of written data. You can
either (a) get the size of the ISO filesystem with cdrecord or
isoinfo, and then use dd to read only what's valid, or complain
to the creator of the CD. There's an option which fixes this,
from memory -dao.
Actually, that doesn't work. I took a random pressed CD, used
isoinfo to find that there were 160525 blocks on it, and then used
dd to read the blocks, with bs=2k count=160525. It stops at 160484
blocks with an IO error every time. Turning off readahead with
hdparm doesn't make any difference. The interesting thing is,
160484 = 2 * 2 * 53 * 757. If this is indeed a block readahead
problem, then the readahead block size is 8k max. (unless it's
106k, but that seems unlikely to me). However, if it's 8k, then it
should read at least up to the last 4 blocks, and not stop 41
blocks before the end.
So, it's either not a block readahead problem, or I'm missing
Could be media, hardware/firmware, or as you say, something we don't understand.
Another thought, with some older cdrecord versions I convinced myself that
using -pad making the ISO image was more successful than using the option
in cdrecord. Don't know if that was/is true or just based on too few trials.
Also seem to remember that readcd works differently with the ide-cd driver.
Too many possibilities, and Joerg is not motivated to do anything with Linux
except whine that the kernel people doing the work won't take orders and
do it his way.
E. Robert Bogusta
It seemed like a good idea at the time