Hi, I've had this sitting in a local tree for a bit (> 12 months - blush!), been meaning to send it here... Its my first dm submission, so please be gentle :) - I'll happily fix up any issues in the patch (or in other metadata) - though I have limited bandwidth to spend on this, so I may not get around to it immediately. The attached patches change dmraid1 to use all backing devices to satisfy read requests rather than just one. The first uses a very simple heuristic - which ever device had the most recent read dispatched to a given location is preferred for subsequent reads. There is an obvious theoretical issue with this: writes move the disk head as well and so effectively should reset allow the devices to the same position. The problem though is that this really is a scheduling problem, and one that the multipath stack would be better at handling. (e.g. multipath shoud be aware of corner cases like : what if there is a dispatched read on the device we think is closest, *after* a write. or what if load isn't being balanced because all the reads are happening in one spot and one device is totally idle). So, I used a very simple heuristic, which works well for me - I get significantly better read performance with the first patch than without. The second patch tweaks the heuristic to handle the case where one disk is being monopolised, which I found happens quite frequently with e.g. kernel builds, where there is a high locality of reference to the content. Again, its not perfect, and in this case there is a horrible magic constant :(. Again, *I* find this a net win, but I have no idea whether other folk will find it so. I had a brief look at making this use multipath instead, but that looks to my naive eye to be both a significant undertaking (which I don't have time for - sorry!) and also perhaps conceptually problematic, as this needs to be an asymmetric multipath: reads can multipath but writes must hit all devices. Cheers, Rob
Attachment:
0001-Load-balance-dm-raid1-reads-by-most-recently-dispatc.patch
Description: Binary data
Attachment:
0002-Force-switching-drives-after-enough-linear-IO-allows.patch
Description: Binary data
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
