If someone is experiencing this can they please do the following:
o add a call to BUG() after the printk in md, line 786 in
drivers/block/md/raid5.c
o build the kernel with kdb enabled
o do an insmod xfsidbg and insmod kdbm_pg
o run until the system crashes.
o use the bt command in kdb to report the stack trace for
this process.
o look at the second argument to add_stripe_bh, use the bh command
on it:
bh 0xaaaaaaaaaa
o send us the output.
It would also be useful to add another printk after line 786 to
look something like this:
printk(KERN_NOTICE "raid5: new bh at blk 0x%x len 0x%x, existing blk
0x%x len 0x%x\n",
bh->b_blocknr, bh->b_size,
(*bhp)->b_blocknr, (*bhp)->b_size);
You can do the latter without all the kdb and panicing the system stuff,
it might be a good starting point.
Steve
> Using XFS (latest 2.4.9-xfs) over raid5 I got a message:
> raid5: multiple 1 requests for sector 24663824
> and the explanation I got from the raid list is:
>
> > It means that while raid5 had an outstanding write request on a
> > particular sector, it received another write request for the same
> > sector.
> >
> > It trys to do the right thing and write them both out in the order
> > that it received them, but it is a bit of a worry that any filesystem
> > would do this. I'm guessing that Andrew is using XFS too. Is that
> > right?
> >
> > While raid5 tries to keep the requests in order, and I suspect other
> > drivers do to, I don't think that it is reasonable to assume that no
> > device driver will ever re-order two requests for the same sector.
> > If I were the author of the filesystem I would be worried.
> >
> > NeilBrown
>
> This truely sounds worrying. Is this OK to be this way or is this
> an issue that needs fixing?
>
> --
> Eyal Lebedinsky (eyal@xxxxxxxxxxxxxx) <http://samba.anu.edu.au/eyal/>
|