On Mon, Dec 15, 2008 at 08:47:24PM -0600, Jon Nelson wrote: > 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). there was a pach to speed up raid10,f2 check in a recent kernel, something like 2.6.27. It did improve thruput from something like 40 % to about 90 %. What kernel are you using? best regards keld -- 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
