On Sat, 27 Nov 2010 19:53:54 +0000 Ben Hutchings <benh@debian.org> wrote:
> Neil, would you mind looking at this:
>
> On Sat, 2010-11-27 at 10:49 +0100, Wouter D'Haeseleer wrote:
> > Ben,
> >
> > I'm running 4 days now without any disk errors anymore.
> > As stated in my previous message this is with the RedHat patch applied.
> >
> > If I compair the patches I see that the patch you grabed upstream does not deal with t->limits.max_sectors
>
> I've tried backporting your commit
> 627a2d3c29427637f4c5d31ccc7fcbd8d312cd71 to Linux 2.6.26 in Debian
> stable but it doesn't seem to fix the problem there. My version is
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=57;filename=0002-md-deal-with-merge_bvec_fn-in-component-devices-bett.patch;att=1;bug=604457>
> and RH's very different patch for RHEL 5 is
> <https://bugzilla.redhat.com/attachment.cgi?id=342638&action=diff&context=patch&collapsed=&headers=1&format=raw>
>
> Our bug log is at <http://bugs.debian.org/604457>.
>
> Ben.
>
Hi Ben,
You probably know most of this, but:
The problem is that with stacked devices, if the lower device has a
merge_bvec_fn, and the upper device never bothers to call it, then the
upper device must make sure that it never sends a bio with more than one
page in the bi_iovec. This is a property of the block device interface.
The patch you back-ported fixes md so when it is the upper device it
behaves correctly.
However in the original problem, the md/raid10 is the lower device, and
dm is the upper device. So dm needs to be fixed.
Despite the fact that I learned about setting blk_queue_max_segments on
the dm mailing list (if I remember correctly), dm still doesn't include
this fix in mainline.
The fix I would recommend for 2.6.26 is to add
if (q->merge_bvec_fn)
rs->max_phys_segments = 1;
to dm_set_device_limits. Though the redhat one is probably adequate.
If you really need an upstream fix, you will need to chase upstream to apply
one :-(
NeilBrown
Attachment:
signature.asc
Description: PGP signature