On Fri, 19 May 2000, Neil Brown wrote:
> - md2 checks b_rdev to see which device was in error. It gets confused
> because sda12 is not part of md2.
>
> The fix probably involves making sure that b_dev really does refer to
> md0 (a quick look at the code suggests it actually refers to md2!) and
> then using b_dev instead of b_rdev.
the fix i think is to not look at b_rdev in the error path (and anywhere
else), at all. Just like we dont look at rsector. Do we need that
information? b_rdev is in fact just for RAID0 and LINEAR, and i believe it
would be cleaner to get rid of it altogether, and create a new
encapsulated bh for every RAID0 request, like we do it in RAID1/RAID5.
OTOH handling this is clearly more complex than RAID0 itself.
> Basically, b_rdev and b_rsector cannot be trusted after a call to
> make_request, but they are being trusted.
yep. What about this solution:
md.c (or buffer.c) implements a generic pool of IO-related buffer-heads.
This pool would have deadlock assurance, and allocation from this pool
could never fail. This would already reduce the complexity of raid1.c and
raid5.c bh-allocation. Then raid0.c and linear.c is changed to create a
new bh for the mapping, which is hung off bh->b_dev_id. bh->b_rdev would
be gone, ll_rw_blk looks at bh->b_dev. This also simplifies the handling
of bhs.
i like this solution much better, and i dont think there is any
significant performance impact (starting IO is heavy anyway), but it would
clean up this issue for once and for all.
Ingo
