Re: linux kernel error reading end of cd/dvd
> 75 sectors is one second CD-DA, right?
Yes.
> > I have observed the same problem with DVD+R burnt by Nero (different
> > box), reading on the box as previously stated, so I don't think it's
> > limited to CDs - it affects DVDs in the same manner.
>
> Can you confirm that the value returned by isoinfo on Nero mastered disk
> did not cross the address of lead-out?
No I can't, I probably don't have the disks any more. The original was
pressed (one of the SuSE 8.2 DVDs), mastered with mkisofs 1.15a27,
copied with Nero. The copy didn't read properly with
dd count=`isoinfo -d`, read error near end.
I doubt Nero would start the lead out before isoinfo -d.
One of the copies I have (probably cdrecord-prodvd):
# dvd+rw-mediainfo /dev/hdb
Media Book Type: A1h, DVD+R book [revision 1]
Legacy lead-out at: 1923680*2KB=3939696640
# isoinfo -d -i /dev/cdrom
Volume size is: 1923680
(Can't get -toc with cdrecord-prodvd to get lead-out because it spits a
fit on this dvdrom drive.)
> > What value do you call "sane" - count=N with N <= isoinfo -d?
>
> "Sane block count" is obviously the number of last *significant* block.
> Yes, for mkisofs mastered images the value returned by isoinfo suffices.
As long as this "sane" value can't be obtained easily, even with
non-mkisofs-mastered disks, it has little practical use. I checked a few
M$-style mass-produced CDs which came with various hardware, and isoinfo
-d was identical to df, all files were readable, not necessarily all
isoinfo -d blocks (last ones give read error).
> If you write the CD on SAO mode (using -dao) the whole CD is readble or
> your drive or kernel is bad.
Out of interest, "whole disk" is how much? Total media capacity before
first burn? That doesn't seem right.
> If you write in TAO mode, then in theory you are not allowed to read more than
> the size value from isoinfo -d.
If I could only read that much... (beyond that number is of no interest
to anyone, well not me).
> As mkisofs at least adds 150 NULLed sectors to this value
"this" = ?
Whenever I checked in the past, the file created by mkisofs -o had a
size (ls -l) identical to the size reported by isoinfo -d. Where are
these 150 blocks added? mkisofs -pad only pads up to the nearest 32k
boundary (i.e. adds up to 15 blocks), and I presume this padding
counts into the isoinfo -d value.
How reliably does isoinfo -d correlate to the size of the filesystem?
100% in case of mkisofs I assume. Are there any counter-examples known
(mkisofs or not)?
> So it seems that as long as the drive gives the correct LBA number
> (should be P-MIN * 60 * 75 + P-SEC * 75 + P-FRAC - 1 with values as
> above), ide-cd will report the correct media size.
Good. The media size can't then be smaller than the filesystem size,
but will be larger if padding is used. On my last CD, readcd reads 16
more blocks before hitting the wall, 15 of which are due to cdrecord
-pad.
> * The SCSI specification allows for the value returned
> * by READ CAPACITY to be up to 75 2K sectors past the
> * last readable block.
What idiot came up with that idea... ?
> Well, it looks like that's up to the drive's firmware. READ CAPACITY
> is pretty much useless, since it's allowed to give wrong
> information.
Ack.
> I can see two options:
>
> 1) Modify ide-cd.c and sr.c to use READ CAPACITY, and then try to
> read the 75 2k sectors before that. Catch the IO error, and adjust
> the capacity based on the number of succesfully read sectors.
>
> 2) Modify ide-cd.c and sr.c to read the TOC and get the capacity
> directly from the disc, thus completely circumventing the READ
> CAPACITY command.
Since READ CAPACITY is braindead, 2) gets my vote. 2) also has the
advantage of not relying on possibly buggy firmware. If one wanted to
put more effort in, one could perhaps take the smaller of 1) and 2).
Surely the drive's firmware itself determines the READ CAPACITY from
the TOC?
Does the block-buffer Andy described handle both hard disks and CD/DVDs
(I understand yes)? There never is a problem with reading past the end
of a hard disk partition (if there was, things would bomb out all
over). Does this mean that in the case of CD/DVDs, the device driver
hands a too-large limit up to higher levels?
Volker
--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.
Reply to: