Thread (1 message) 1 message, 1 author, 2006-06-09

Re: raid 5 read performance

From: Neil Brown <hidden>
Date: 2006-06-09 22:59:21

On Friday June 9, raziebe@gmail.com wrote:
Neil hello

Sorry for the delay. too many things to do.
You aren't alone there!
I have implemented all said in :
http://www.spinics.net/lists/raid/msg11838.html

As always I have some questions:

1.  mergeable_bvec
     I did not understand first i must admit. now i do not see how it
differs from the
     one of raid0.  so i  actually copied it and renamed it.
Sounds fine.  For raid5 there is no need to force write requests to be
split up, but that's a minor difference.
2. statistics.
    i have added md statistics since the code does not reach the
statics in make_request.
    it returns from make_request before that.
Why not put the code *after* that?  Not that it matters a great deal.
I'll comment more when I see the code I expect.
3. i have added the new retry list called toread_aligned to raid5_conf_t .
    hope this is correct.
Sounds good.

4.  your instructions are to add a failed bio to sh, but it does not
say to handle it directly.
    i have tried it and something is missing here. raid5d handle
stripes only if  conf->handle_list is not empty. i added handle_stripe
and and release_stripe of my own.
   this way i managed to get from the completion routine:
   "R5: read error corrected!! " message . ( i have tested by failing
a ram disk ).
Sounds right, but I'd need to see the code to be sure.
5. I am going to test the non common path heavily before submitting
you the patch ( on real disks  and use  several file systems and
several chunk sizes).
I'd rather see the patch earlier, even if it isn't fully tested.
 It is quite a big patch so I need to know which kernel do you want me
to use ? i am using poor 2.6.15.
A patch against the latest -mm would be best, but I'm happy to take it
against anything even vaguely recent.

However, it needs to be multiple patches, not just one.
This is a *very* important point.  As that original email said:

  This should be developed and eventually presented as a sequence of
  patches.

There are several distinct steps in this change and they need to be
reviewed separately or it is just too hard.
So I would really like it if you could separate out the changes into
logically distinct patches.
If you can't or won't, then still send the patch, but I'll have to
break it up so it'll probably take longer to process.


Thanks for your efforts,

NeilBrown
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help