Started rewriting the pktcdvd driver to be more modular. It needs to be split a bit, since CD-R and CD-RW writing are very different. At the same time I want to clean up the request handling, so it actually uses the exported function and doesn't mess too much with the block level internals. The latter was particularly bad, since it meant that there was lots of stuff I needed to do myself that I really had no business messing with.

Linus integrated my block per-queue freelist and modular elevator patch, after a discussion spawned about his unhappiness with the current setup. I implemented a new elevator based on his ideas (elevator_linus_*) which is the default now. Of course a couple of bugs showed up after integration, but I guess that's the way it always goes -- I have fixed these now.The only thing I need to do now is audit all block drivers and make sure they do the right thing wrt blk_init_queue and blk_cleanup_queue. If not, we could end you leaking requests as time passes (requests are not located in a static table anymore, instead we allocated them from a dedicated slab cache). I've already fixed IDE, SCSI is next. After that, I don't think there are any left. The patch for loop I pushed sometime ago, just in case the merge happened before 2.4.

A couple of stupid errors snuck into packet-0.0.2a release. First of all, the io_request_lock booboo mentioned below. And then I rediscovered (yes, I've done this before) that SCSI uses the request queue queuedata field to store the pointer to the SCSI device. So now I have to copy that and hack around it. Ben created a CDRW branch of the UDF cvs tree, which has the block_empty function to query blocks for data. I'll release a packet-0.0.2b later today with these fixes, plus include the code to query for empty blocks. This last part alone should give us a _huge_ speed increase! I'll be testing just how much before releasing.

Battling with IDE locking, it's a big mess... I've taken the task of rewriting the internal locking upon me, let's see how this goes.

Hey, it's been a while since my last update! I'm so bad at keeping diaries... But here goes ->

Released a new packet-writing package. This time it is fairly solid for me, not even untarring a complete kernel source tree to disc made it fall to its knees. The SGI kdb kernel debugger is included in the patch, I hope this will make it easier for folks to submit bugs. It's easier for me to trace them, which was the main reason for the inclusion. You can find the 0.0.2a release in here or at other kernel.org mirrors. Be sure to apply the -inc patch on top after patching, there were two stupid typos in the release.

Sent Andre an updated block queuing / elevator patch, and apparently it solves the weird problems he (and doc) has been seeing when really pushing IDE. I don't see quite how yet, but it points to a bug in the current elevator. kdb back traces all point to the stuck processes waiting in __wait_on_buffer indefinately - a sure sign that we are missing a buffer of a request here of there. I need to look at this some more, though.

Was sent an interesting paper on optimizing elevators for newer disk drives. When I've actually finished reading this, it'll be fun to hack this into Linux and see what kind of improvements it gives. I am an I/O nut, you know...

People are seeing very nice improvements with my block + elevator patch, that is good news. I suppose I should split it up a bit and get around to shipping it to Linus... I added more parts to it today, a much better version of the tq_disk I did earlier. Now we don't use task queues to handle plugging, but rather tasklets (or softirq's). This made it easier and more clean to implement firing of individual devices when in need of a buffer/page/kio. This means that now firing all devices is not the main use, it can still do that however. We need that for memory pressure reponse, etc.

I'm seeing an odd XFS crash when really pushing it. I'm hoping the XFS guys will fix this soon.

Oops, haven't updated in a couple of days...

Wrote the code to support KIOBUF_IO that SGI uses in their XFS file system pagebuf. Unfortunately there's something up with the XFS cvs right now (unable to obtain lock bla bla), so I can't diff it and send it to Chaitanya, hopefully it'll be back up tomorrow. Gave me a chance to test the new Maxtor drives I have received, they are working great. SCSI still has quite a performance edge, though.

Also finished the last updates to 2.2.16-pre and sent them to Alan. I think I made it just before he left ;-).

My CX drive is stuck in Hannover according to the UPS package tracker. I hope they can get it here by tomorrow so that I can start hacking on pktcdvd again this weekend. My fingers are really itching to get back to that... Preparing for the worst case scenario (that I still can't get my data out), I checked with Ibas how much a data recovery operation would cost. An analysis is $475, recovery estimated between $975 and $1800. Auch.