Re: Awful Raid10,f2 performance

["Keld Jørn Simonsen" <keld@dkuug.dk>]

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@suse.de> wrote:
> > On Monday December 15, jnelson-linux-raid@jamponi.net 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