]> err.no Git - linux-2.6/commitdiff
[PATCH] md: improve read speed to raid10 arrays using 'far copies'
authorNeilBrown <neilb@suse.de>
Mon, 28 Nov 2005 21:44:09 +0000 (13:44 -0800)
committerLinus Torvalds <torvalds@g5.osdl.org>
Mon, 28 Nov 2005 22:42:25 +0000 (14:42 -0800)
raid10 has two different layouts.  One uses near-copies (so multiple
copies of a block are at the same or similar offsets of different
devices) and the other uses far-copies (so multiple copies of a block
are stored a greatly different offsets on different devices).  The point
of far-copies is that it allows the first section (normally first half)
to be layed out in normal raid0 style, and thus provide raid0 sequential
read performance.

Unfortunately, the read balancing in raid10 makes some poor decisions
for far-copies arrays and you don't get the desired performance.  So
turn off that bad bit of read_balance for far-copies arrays.

With this patch, read speed of an 'f2' array is comparable with a raid0
with the same number of devices, though write speed is ofcourse still
very slow.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
drivers/md/raid10.c

index 867f06ae33d944e8ef7178d28fc3fa8905d963b3..713dc9c2c73093a67348e473f2bfc47f888d6e3c 100644 (file)
@@ -552,7 +552,11 @@ static int read_balance(conf_t *conf, r10bio_t *r10_bio)
                    !test_bit(In_sync, &rdev->flags))
                        continue;
 
-               if (!atomic_read(&rdev->nr_pending)) {
+               /* This optimisation is debatable, and completely destroys
+                * sequential read speed for 'far copies' arrays.  So only
+                * keep it for 'near' arrays, and review those later.
+                */
+               if (conf->near_copies > 1 && !atomic_read(&rdev->nr_pending)) {
                        disk = ndisk;
                        slot = nslot;
                        break;