Thomas Schmitt wrote:
The readahead size can be set by the 'blockdev' command, but smaller sizes hurt performance.Hi, Dave Platt wrote:Unfortunately, determining the end-of-data (end-of-track) location on a data CD is one of those things which is difficult-to-impossible to do reliably.This is actually a matter of the device driver and not so much of drive and media. The size of a logical track as obtained by MMC commands is reliable. One just has to be aware that not all types of sectors can be read by the SCSI command for reading data blocks. In the special case of CD TAO data tracks there are two such non-data blocks at the end of each track. (Not related to Darth Bane's Rule Of Two.) With CD SAO data tracks there are no such non-data blocks in the range of the official track size. All DVD types seem to be clean in that aspect, too. (No non-data sectors are defined for non-CD in MMC.)- The last data block reads back reliably. Attempting to read the block following it does return an error, but only after a substantial delay. - The last data block (or even the last couple of data blocks) are unreadable. Attempting to read them results in an I/O error. ... when transitioning between tracks having different modes ...The behavior of the Linux block device driver created several urban legends. To my theory it reads in larger chunks up to the track end. When the last chunk of a TAO track is read, the two unreadable sectors are encountered and let the whole chunk fail. If the driver would retry with a chunk size that is two sectors smaller, then it would be ok. But the driver does not. It just declares i/o error. I believe the error was fixed a few kernel versions ago, so that a clean partial read count is returned. I haven't validated that for all write modes, and perhaps I should for purposes of discussion. Chunk size is smaller than 300 kB. That's why that size of padding is a traditional remedy for track content which can recognize its proper end. Whatever, if you read the CD TAO track by own SCSI read commands it is easy to retrieve the exact amount of data which has been written to that track. libburn test program telltoc can demonstrate that. The readable amount includes any padding by formatter and burn program, of course. So padding, which helps with the block device driver, is rather counterproductive if you have a reader which works flawless. With a correct reader one has to memorize the amount of padding and ignore that many bytes at the end of the data. Padding at write time and ignoring pad bytes at read time is just a guess how to fool the CD TAO bug in the Linux driver. Bill Davidsen wrote:The data is in 64k chunks, so all writes are sector complete. I haven't had any issues with reading the data off DVD, or off CDHaving data aligned to a size larger than 2 blocks (= 4 kB) can be another remedy for the driver problem. It depends on the assumption that the driver will not attempt to read ahaead of the data amount which is demanded by the user space program. Large alignment size will probably help to fulfill that assumption. Have a nice day :) Thomas -- E. Robert Bogusta It seemed like a good idea at the time |