Re: HELP: Getting unexpected fakeraid behavior. Fix?

["Timothy Normand Miller" <theosib@gmail.com>]

I have absolutely no idea what I'm doing, but the kernel source is
well formatted.  Here's what I found.  I'm looking in
"drivers/md/dm-raid1.c".

There's this function that seems to be involved in initiating reads:

static void do_reads(struct mirror_set *ms, struct bio_list *reads)
 970{
 971        region_t region;
 972        struct bio *bio;
 973        struct mirror *m;
 974
 975        while ((bio = bio_list_pop(reads))) {
 976                region = bio_to_region(&ms->rh, bio);
 977                m = get_default_mirror(ms);
 978
 979                /*
 980                 * We can only read balance if the region is in sync.
 981                 */
 982                if (likely(rh_in_sync(&ms->rh, region, 1)))
 983                        m = choose_mirror(ms, bio->bi_sector);
 984                else if (m && atomic_read(&m->error_count))
 985                        m = NULL;
 986
 987                if (likely(m))
 988                        read_async_bio(m, bio);
 989                else
 990                        bio_endio(bio, -EIO);
 991        }
 992}

It calls this function:

866static struct mirror *choose_mirror(struct mirror_set *ms, sector_t sector)
 867{
 868        struct mirror *m = get_default_mirror(ms);
 869
 870        do {
 871                if (likely(!atomic_read(&m->error_count)))
 872                        return m;
 873
 874                if (m-- == ms->mirror)
 875                        m += ms->nr_mirrors;
 876        } while (m != get_default_mirror(ms));
 877
 878        return NULL;
 879}

which seems to always choose the default mirror unless there's an
error on the default mirror.  I have absolutely no idea where to put
it, but it seems to me that a solution would be to keep track of the
last mirror and select the next one each time this function is called.

That would be a simple and blind round-robin, which isn't necessarily
the smartest thing to do, so it would require testing.  It also occurs
to me, given how long this code has been around (since 2003), that the
idea of distributing the read load may have been considered and
rejected.  Was it?  If not, this could be a valuable boost to Linux
RAID performance.  (I chose RAID1 both for the redundancy AND the read
performance boost, and so I was surprised to find that there was no
read performance boost under Linux.)

What is dm-round-robin.c for?  Is there a place where the kernel
source is heavily annotated so that a newbie can navigate it and
figure out what does what?

Cheers.

-- 
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project