On Mon, Mar 04 2002, Peter Osterlund wrote:
The interesting change in this version is that I have changed the way mixing of read and write requests is handled. The driver now inserts a "synchronize cache" command before the first read command following a write command. This has three advantages:
That's a good idea, I definitely agree with that. Some comments on the implementation -- I'd much rather see this done at the lower level, so ide-cd or sr would sync cache on the first read on its own.
I didn't know if this behaviour is always wanted, since there are so many different modes for CDs, and I don't know enough about them all. If it is always wanted, I agree it would be better to put this functionality at a lower level.
If we are seeing this problem on cd-rw writing, then I bet the problems will be pretty much identical for any type of 'write lots of stuff, now start read' type of access.
The implementation might be a bit nastier though, as you would have to handle that async and not blocking like you do now.
For the 2.5 version of the packet driver, doing the syncs at a lower level may actually simplify things. The 2.5 version is not limited to handling of a single packet at a time. A state machine is used for driving each packet and the packet driver can submit multiple reads and writes asynchronously to the underlying cdrom device queue, which is then responsible for sorting and merging the requests. In this scenario it
Good
would be quite hard for the packet driver to insert cache sync commands at the right spots in the request queue without limiting the amount of request reordering the underlying CD queue can do.
Indeed, that this point it's pretty much a requirement that the lower level does it. Although in 2.5 you could do cool stuff like actually prefill a cache flush cdb inside the request and add it directly to the target queue.
2. Since everything is now done with "bio" objects, the functionality to fill in missing parts of packets with data from the buffer cache doesn't work.
Since basically everything is in the page cache these days, you might as well just ignore the buffer cache completely and just to page cache lookups. What I had in mind was something like: - on write to packet device, allocate a bio big enough to hold the entire packet. - have packet elevator just fill in the bio_vecs on merged writes - fill in bio_vecs with pages from the page cache You will probably need a bit of logic to clean the buffers on the page on end I/O (maybe even pre-clean them so a different writer won't be stuck on locking the buffer for writeout, only to wakeup when the buffer has been cleaned elsewhere). I can try something like this in the 2.5 tree when I get back from Norway. I plan on getting the 2.5 stuff in shape (seems it's already pretty good, excellent work Peter!) and getting it in the kernel very soon now. Peter, I hope you don't mind, but I do consider you the 2.4 maintainer of the patch these days. You have been the defacto maintainer for quite some time anyways. -- Jens Axboe