Vojtech & Coly--- Thanks for feedback! On Wed, Sep 20, 2017 at 1:08 AM, Vojtech Pavlik <vojtech@xxxxxxxx> wrote: > On RAID devices, bcache attempts writing out full RAID stripes, avoiding > the issue you describe. > > It might make sense to extend that logic to non-striped devices, too. Yes-- it tries to write full stripes. OTOH it doesn't favor contiguous sets of full-stripes, and if there's not a lot of full-stripes (500-- fairly unlikely, especially with sequential I/O bypassing the cache) it falls back to the other behavior and will happily pick the smallest blocks. So it's still not seek minimized in either case. The data structure used for full-stripes would be not too bad to scan to look for very large chunks. I am not sure if we should, though, as it is likely to destroy the LBA-ordering properties. That is, there's a definite tradeoff between trying to do the I/O in order and trying to do the biggest I/Os. For now I think I am going to put the heuristic in the fallback (not-striped) case-- so on a striped array, first we'll search the entire disk for full-stripes, then try to get bigger-than-average reads, and finally fall back to anything we find on the way. >> [snip] > It doesn't sound wrong. :) > > Vojtech Awesome. :D I have some preliminary measurement that this is a win-- I'll work on getting a good patchset together some time in the next week. Thanks, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
