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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]