Re: linux kernel error reading end of cd/dvd
> > > 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 never claimed I have all the answers! I just tried to give most
accurate definition and applied it to a particular case:-)
> I checked a few
> M$-style mass-produced CDs which came with various hardware, and isoinfo
> -d was identical to df,
df output equals to isoinfo -d per definition. I mean df *always* shows
same value as isoinfo (provided that we keep talking about single
session media:-). It's simply two ways to examine same value, so it does
not prove anything. What you should compare it with is lead-out
location.
> all files were readable,
Once again. All files being readable is what basically counts. Yes, we
have formal right to expect kernel to provide for direct access to
/dev/cdrom as well, but only if it's free from technicalities specific
to media manufacturing, recorder firmware implementation, player
firmware implementation, etc. Bypassing the block buffer and finding
"sane block count" is a way of telling to the system "I'll take care of
technicalities" and I think that we should *just do* that.
> not necessarily all
> isoinfo -d blocks (last ones give read error).
Then play with programs in mkisofs/diag, make one to print last
significant block of file system to figure this one out...
> The media size can't then be smaller than the filesystem size,
For mkisofs mastered images!!! But generally speaking there is nothing
preventing you from putting value of 500MB to volume descriptor (value
returned by df and isoinfo), having last significant block at 300MB and
burn 400MB on the media. The media will be perfectly mountable, all
300MB worth files will be accesible, df will return 500MB and lead-out
will be at 400MB...
> > * 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... ?
It's the way CD media is. The catch is that MSF addressing information
is smashed across the whole block [in one of those side channels] and
transition between two streams (data to lead-out in this case) always
has a window of uncertainty. DVD is completely different story.
> > 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.
Who said it's wrong? The fact that it's not what you expect it to be in
some particular situation doesn't necessarily mean it's wrong! OK, I
have to admit that I might have mislead you people by calling it READ
CAPACITY as it was a media capacity in respect to read operations, but
the fact is that it's just a name of command reading a media capacity,
not necessarily in respect to read operations.
> Does the block-buffer Andy described handle both hard disks and CD/DVDs
> (I understand yes)?
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?
Yes, and under some circumstances it's more or less intentional (e.g.
random access DVD+RW), or hard to predict (e.g. CD player can't tell
apart media recorded in DAO and TAO, while TAO media is guaranteed(?) to
have unaccessible blocks before lead-out). But what makes us human
geeks? Ability to adjust to situations! So bypass the block buffer and
figure out "sane block count" in user land:-) Cheers. A.
Reply to: