[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Using dd to verify a dvd and avoid the readahead bug.



Hi,

Patrick Ohly:
> Writing 150 empty blocks after the last block with user data is required
> by the data CD standard - they are called "post-gap".

Yep. But as the publicly available standard MMC-5 clarifies:

"6.33.3.19 Post-gap
 If a Data track is followed by another kind of track
 (such as an audio track), this Data track ends with a post-gap.
 A post-gap is placed at the end of a Data track, and is part of
 the Data Track. A post-gap does not contain actual user data.
 The minimum length of post-gap is 2 seconds. The Drive does not
 perform any action for a Post-gap.
"

This is not the situation we have with a single TAO track
on closed media, unless you call the end of media "another
kind of track".

Also: i do not have this "readahead" problem with SAO sessions.
And all my drives can read TAO tracks up to the last 2 non-data
sectors if i apply SCSI command READ 10.

All payload and all padding is retrievable up to the last byte !
It is not an issue of the drives but of the operating system.

To me it appears like the block device driver of the kernel
is overly trusting towards the TOC of the media.
The TOC says payload+2 sectors, the driver tries to read that
many sectors, the last buffer chunk encounters an error,
the driver does not re-try to read the last payload sectors in
2 kB steps but pretends they are ill.

This explains nicely why the number of missing bytes varies
on my system with the CD media i insert. It also explains why
SAO data sessions do not show the problem for me.


The standard and the tradition of this whole issue is so
messy, nevertheless, that the man page of my burn backend cdrskin
advises padsize=300k in all its examples with data tracks.


> Later (Feb 15 2003) Joerg changed mkisofs so that it always adds 150
> blocks.

Seems to be a wise decision, although the problem is a media+drive
issue and actually belongs into the realm of the burn software.

But the whole mess is intransparent enough that 150 extra
sectors are a low price for universal readability.


Have a nice day :)

Thomas



Reply to: