Neil,
I've implemented the improvements that you've suggested below, and preliminary tests are showing some very good results!
The latest patches are available at:
http://www.parisc-linux.org/~jejb/md_bitmap/
Further details below...
Thanks, Paul
Neil Brown wrote:
It's looking a lot better. I can start focussing on deeper issues now.
It really bothers me that all the updates are synchronous - that isn't a good approach for getting good performance.
Yes, that's quite true. In fact, in my simple write performance tests I used to see a slowdown of around 30% with the bitmap file...now, the difference is not even measurable! (This is with the bitmap file located on a dedicated disk, in order to reduce disk head movement, which tends to degrade performance).
This is how I think it should happen:
When a write request arrives for a block where the corresponding bit is already set on disk, continue with the request (as currently happens).
When a write request arrives for a block where the corresponding bit is *not* set on disk, set the bit in ram (if not already set), queue
the write request for later handling, and queue the bitmap block to
be written. Also mark the queue as "plugged".
When an unplug request comes, Send all queued bitmap blocks to disk, then wait for them all to complete, then send all queue raid write requests to disk.
When a write request completes, decrement the corresponding counter but don't clear the "shadow" bit if the count hits zero. Instead flag the block as "might have unsynced-zeros".
The write-back thread slowly walks around the bitmap looking for blocks which might have an unsynced zero. They are checked to see if they still do. If they do, the disk-bit is cleared and the disk-block is queued for writing.
There might need to be a couple of refinements to this, but I think it is the right starting point.
I've implemented more or less what you've described above in this latest patch.
With this approach you wouldn't need the "bitmap_update" in r1bio_s as the write-back daemon doesn't have a list of things to do, but instead it periodically scans to see what needs to be done.
Yes, getting rid of the bitmap_update structure was a very good idea. The code is much cleaner without that...
- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
