Hi, I thought a bit more about the speed throttling I put in the latest release, and basically came to the conclusion that it shouldn't really be there. The low level drivers do their own retries of requests, and should do their own throttling too. Basically, when pktcdvd gets an I/O error from the lower layers the low level driver ought to have exhausted all possibilities wrt recovery. There's no point in doing retries etc at multiple levels, in fact it's pretty stupid. So I'm taking this code out again. But then, what should pktcdvd do on an I/O error? It should remap the packet location and resubmit the write. Ben, should we finally get this done? It's the last step in solid cd-rw writing, and absolutely critical if it's to be trusted. The problem with cd-rw is that UDF basically has to handle bad blocks and remapping. This is just one of the things that make it horrible to support, and why the format sucks. This sort of thing should be handled in hardware, like it is for any sane media. UDF will do its own read remapping for already remapped blocks I pressume (Ben?), if not pktcdvd can easily do it too (as long as I can get at the remap table). For writes, UDF needs to assign me a new start location for the packet. (UDF should to this too, but that would be much harder to support so I think for now we should let pktcvd do it). Comments? -- Jens Axboe