lkml.org 
[lkml]   [2000]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject"Got md request ..." pointer ... Was: Re: First draft list of 2.3.x "Things to fix"
On Tue, Jan 11, 2000 at 12:51:06PM -0500, Kristofer T. Karas wrote:
> Alan Cox wrote:
>
> > The order is approximate priority. It may also not be totally accurate.
> > Suggestions/fixes welcome.
>
> Until some kind soul submits an elegant fix, I will take even a completely
> buggered fix for anything that makes it impossible to even run a 2.3.x kernel;
> the one that affects me (and anybody else out there???) is the MD driver:
> * "Got md request, not good..."
> I can't even boot up /sbin/init. :-(
> If RAID 0.90 addresses this, fine; but if not, or that isn't going in for
> awhile, then I would sure hope that the popular work-around floating about (or
> some facsimile) will be applied in the interim.

The Raid drivers dont address this problem - It is seem with the LVM
and the raid code (New and Old afaik).

There has been a dirty fix a couple of days ago ... I found it on deja.com


On 1999-12-17 Mike Galbraith <mikeg@weiden.de> wrote:
> On Thu, 16 Dec 1999, Richard Gooch wrote:
>
> > Hi, all. I've just noticed that MD (with raid0) is broken in
> > 2.3.33. I get the following message:
> > Got md request, not good...
> >
> > This seems to be because DEVICE_REQUEST() is being called (which is
> > defined to be do_md_request(). Perhaps the block device request queue
> > changes is to blame? I didn't have this problem with 2.3.31.
> >
> > Anyone got a patch to fix this?
>
> Not a patch, but I did get it working. Yesterday I beat the living _tar_ out of my box and it
> works perfectly.
>
> The trouble (afaikt) is two fold..
>
> make_request() pulls the wrong queue for a raid device via
> q = get_queue(bh->b_dev)
> and then does
> if( !q->plugged )
> (q->request_fn)(q);
> which leads directly to do_md_request().
>
> ll_rw_block() contains..
>
> for (i = 0; i < nr; i++) {
> set_bit(BH_Req, &bh[i]->b_state);
> #ifdef CONFIG_BLK_DEV_MD
> if (MAJOR(bh[i]->b_dev) == MD_MAJOR) {
> md_make_request(bh[i], rw);
> continue;
> }
> #endif
> __make_request(q, MAJOR(bh[i]->b_rdev), rw, bh[i]);
> }
>
> .. ie it wants to substitute it's own handling where there is a
> handler (raid1/5), but in md_make_request() at the point where
> you fall through, you hit make_request() instead of the intended __make_request().
>
> What I did (because get_queue() and __make_request() are static) was to clone make_request() and
> call it make_request_redirect(). It is identical to make_request except it does..
> q = get_queue(bh->b_rdev) << remember this 'difference'
>
> The workaround (bandaid) in md_make_request() looks like this.
> err = mddev->pers->make_request(mddev, rw, bh);
> } else {
> extern void make_request_redirect(int,int,struct buffer_head *); make_request_redirect
> (MAJOR(bh->b_rdev), rw, bh);
> err = 0;
> }
>
> Comment out the printk in do_md_request(), apply the same bandaid to raid1.c and raid5.c and
> you're done.
>
> I have one tiiiiny little problem with this 'fix'. If you look at ll_rw_block() a few lines up
> from md_make_request(), you'll see.. /* Md remaps blocks now */
> bh[i]->b_rdev = bh[i]->b_dev;
>
> I <zzzt> don't get it, but <zzzt> it works. I'll wait for the movie.
>
> -Mike


This fix is probably only a pointer to the right direction

This problem basically prevents us from using raid0s of raid5s which
i tried (but failed). It occures with the LVM under high load as
Heinz told me. 2.2 is also affected.

Flo
--
Florian Lohoff flo@rfc822.org +49-5241-470566
... The failure can be random; however, when it does occur, it is
catastrophic and is repeatable ... Cisco Field Notice


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.078 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site