On Mon, Dec 15, 2008 at 3:38 PM, Neil Brown <neilb@xxxxxxx> wrote: > On Monday December 15, jnelson-linux-raid@xxxxxxxxxxx wrote: >> A follow-up to an earlier post about weird slowness with RAID10,f2 and >> 3 drives. This morning's "check" operation is proceeding very slowly, >> for some reason. ... >> What might be going on here? > > If you think about exactly which blocks of which drives md will have > to read, and in which order, you will see that each drive is seeking > half the size of the disk very often. Exactly how often would depend > on chunk size and the depth of the queue in the elevator, but it would > probably read several hundred K from early in the disk, then several > hundred from half-way in, then back to start etc. This would be > expected to be slow. An excellent explanation, I think. However, not to add fuel to the fire, but would an alternate 'check' (and resync and recover) algorithm possibly work better? Instead of reading each logical block from start to finish (and comparing it against the N copies), one *could* start with device 0 and read all of the non-mirror chunks (in order) but only from that device, comparing against other copies. Then md could proceed to the next device and so on until all devices have been iterated through. The advantage to this algorithm is that unless you have > 1 copy of the data on the *same* device the seeking will be minimized and you could get substantially higher sustained read rates (and less wear and tear). -- Jon -- 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
