On Sun, 2010-11-28 at 08:28 +1100, Neil Brown wrote: > 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. Thanks, I didn't spot that subtlety. > 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 :-( I won't do that myself - as you can see, I don't really understand the issue fully. Is that fix also valid (modulo renaming of max_phys_segments) for later versions? Ben. -- Ben Hutchings, Debian Developer and kernel team member
Attachment:
signature.asc
Description: This is a digitally signed message part