[ Monday, January 10, 2000 ] Jochen Scharrlach wrote:
> James Manning writes:
> > What worries me is that what looks like is happening is that the
> > md-layer is passing a very-invalid sector request (for whatever reason
> > it got that far) down to the devices making up your raid1 and since the
> > ll_rw_blk::make_request() fails the md-layer tags that as a failing device
> > (without having checked the request against valid size itself) and moves
> > on, failing on successive devices (same reason, esp. in raid1 :) until
> > it gives up and just reschedules the block all over again, eventually just
> > failing altogether.
> >
> > Is this a correct interpretation? If so, it seems like either struct
> > mddev_s or struct mirror_info needs a size/sect_count/whatever parameter
> > added to check against the buffer_head being requested... I don't see
> > a make_request path back that can handle this case on its own...
>
> So it's a bug in the raid code or is the raid-device corrupted? What
> might happen if I reboot the whole machine? It's a production server,
> so I'm quite nervous...
My guess would be (although I'm certainly looking forward to other views)
is that possibly fs corruption messed up some of the ext2 indirect blocks
(squid cache I believe you mentioned) and so request for that data went
to invalid places on the block device.
What frightens me is that this invalid request caused the md-layer to
misinterpret the failed ll_rw_blk work as a failed device. The md-layer
should only be turning off devices when "real" errors are returned,
and it would appear that unless *make_request() changes, the md-layer
will have to keep track of its own logical size and check requests before
passing them down. With that same basic check occuring down in the
ll_rw_blk code (esp. in raid1) I'm sure this isn't desired but I'm
not sure I see an alternative.
> The other thing I changed on this server, was to integrate a Tekram
> DC395UW controller only for the QIC, but this should have no effect,
> should it?
I can't really say what caused the problem, and I'm not even sure it's
ext2 corruption causing the invalid request, but I want to make sure
I diagnose (and if incorrect, get corrected :) this as the md-layer
incorrectly translating the failed make_request() to ll_rw_blk.c as a
drive failure.
Your case happens to make this painfully easy (at least in a cursory
glance) since you use the same drive in so many different md arrays :)
James
--
Miscellaneous Engineer --- IBM Netfinity Performance Development
