Hi, Next pre is up, changes since pre2: - Remove rq->cmd checks in merge functions, only WRITEs now - Fix io_request_lock lockup when used with ATAPI (req->end_io) - Throttle down write when failed and retry, should write OPC entry when this happens - Use current time for b_flushtime in buffer.c for packet device, we don't want to postpone flushing a buffer if it causes read gathering - Remove all bh->b_private references, we could be stomping on other users (highmem, most notably). - Always use pkt_end_io_write as our bh->b_end_io callback - Added write caching config option (don't use yet) - Added UDF empty block querying option - Fixed missing brelse() for buffers stolen from buffer cache - Combine pkt_init_bh and pkt_recount_segments to only do one scan of request (pkt_init_rq) - Fix dupe buffer_head in pkt_hole_merge - Change buffer_head sequence check in ll_rw_blk, add to SCSI end_request handling and it's been merged to 2.4.4-pre6. I'll hang on for final 0.0.2i until 2.4.4 is really released. *.kernel.org/pub/linux/kernel/people/axboe/packet/ As usual, there's a pre2 -> pre3 ugrade patch too. However, this one doesn't catch pre5 -> pre6, so I suggest getting 0.0.2i-pre3 from scratch. SCSI (Plextor 12/4/32) and ATAPI (Sony CRX100E) tested to the extent that large file copying was verified correct (100MB random data file), untarring 2.2.19 kernel source (and compiling it!), and various small files. No data loss of corruption detected, and it was all checked down to the very last byte. ATAPI used DMA mainly, PIO has also been tested good on this drive (just a large file copy, sanity verify). Note: although stuff like copying/untarring a kernel tree seems like fun, it isn't really a decent way to use packet writing. The pktcdvd module will do all it can to merge small writes together, but for decent performance one really should tar up small files before writing them to disc. For example, doing a make dep run on the 2.2.19 source ends up reading half the stuff from disc. Some writers are better at doing this quickly than others, the Sony beats the Plextor hands down in this sort of test (turning off laser, reading blocks, turn on and write). For the 100MB file copy, read gathering is almost exclusively due to getting the remaining parts of the packet that the UDF sparing table is written to. This is something we can't avoid (the WRITE), however I have plans for at least pinning the remaining blocks in memory. Right Ben? :-) Then arge file writes should go as fast as packet writing can go on your drive. Don't ask how long it takes to run make dep bzImage on a cd-rw stored kernel :-) (Un) fortunately I haven't had any failed writes on this particular disc just yet, so the write throttling path has not been exercised at all. It could be severly broken :-) Adam, I'll take a look at your scatter gather segment miscount next. I suspect this happens because of a requeue of the request. -- Jens Axboe