Re: linux kernel error reading end of cd/dvd
Meet the players in the field:
- block buffer which provides for read-ahead, I/O requests' slicing and
coalescing;
- value returned by READ CAPACITY command, hereafter simply READ
CAPACITY;
- actual lead-out position;
Rules of the game (please note that I'm not claiming that I know all the
rules in detail:-):
- block buffer rearranges I/O depending on *momentary* availability of
spare memory, e.g. even if you ask for bs=2k, it may coalesce them to
e.g. 126KB chunks, or it may break larger requests to a number of 4KB
ones;
- no requests are posed beyond the READ CAPACITY;
- READ CAPACITY coincides with lead-out position most of the time, *but
not always*;
- CD lead-out position is documented to be inaccurate [with 75 blocks
inaccuracy?], DVD lead-out position is believed to be accurate;
- CD lead-out is preceded by few unaccesible blocks (unless disk is
recorded in DAO mode?), lead-out itself is unaccesible;
Last and middle "rules" form the ground for I/O errors in general and in
read-ahead in particular. The first "rule" explains why the problem with
dd count=X appears to be intermittent. It also makes it impossible to
find the magic "modulo coefficient," which would predict if any
particular combination of bs=, count= and READ CAPACITY is bound to fail
or not [as it all depends on *momentary* availability of spare memory].
Bypassing the block buffer naturally makes all the problems with
count=<sanevalue> disappear, as well as makes it possible to accurately
and reliably locate the last accessible block.
Relevant question is when READ CAPACITY is not equal to lead-out offset?
I don't know about CD, but in DVD case most units would report full
media capacity for READ CAPACITY under following circumstances:
- DVD+RW and DVD-RW Restricted Overwrite(?) media in recorder unit. READ
CAPACITY is not associated with lead-out position and equals to full
media capacity;
- DVD-RW Restricted Overwrite, Incremental DVD-R[W] and DVD+R which were
not finalized in first session in legacy DVD-ROM unit. Unit replies with
full media capacity (as legacy lead-out points to the outer edge);
[- if you [still] have DVD+RW kernel patch applied, it will also
*replace* the READ CAPACITY with full media capacity for DVD+R media in
recordred unit];
> > I tried mounting the CD that did not work, and copy all files off of
> > it. No problems there.
>
> Note this is not necessarily an indicator that the filesystem is not
> affected, it only means none of the files are directly affected.
But that's basically what should and does count...
> There
> are more blocks in a filesystem than just the files' data.
If we're talking about ISO9660 layout prepared by mkisofs, then those
"more blocks" are known to be insignificant and you can as well checksum
every file instead of the whole filesystem image, can't you? Does it
really have to be whole image? But in either case. One can wonder if the
common block buffer could do better job spotting the last addressible
sector? Well, yes, but do keep in mind that it's a *common* block
buffer, which is not aware of CD technicalities... So that I'd say that
it's perfectly legitimate to advice as following. If you really have to
checksum the whole image, then make sure to bypass the block buffer
*and* provide sane block count value. A.
Reply to: