[DRBD-user] "kernel: bio too big device drbd0"

Lars Ellenberg lars.ellenberg at linbit.com
Fri Jun 7 14:03:00 CEST 2013

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


On Fri, Jun 07, 2013 at 12:26:10PM +0200, Sebastian Riemer wrote:
> On 06.06.2013 18:30, Lutz Vieweg wrote:
> >>> Should I be worried?
> >>
> >> It depends on how the layers above react on this situation. If they try
> >> again with smaller IOs, then it's okay. Otherwise, there can be a major
> >> issue. Kernel code has to be read to verify.
> > 
> > I could not find the right place to look at in drivers/md/dm-crypt.c,
> > do you have a suggestion?
> 
> The queue limit stacking is in drivers/md/dm-table.c function
> "dm_calculate_queue_limits()". It uses "blk_set_stacking_limits()" in
> kernel 3.7.6. So it gets correct limits once upon getting a new dm table.
> 
> I also had a look at the latest DRBD 8.4 source. They still mess around
> with the blk queue limits. Set it larger, set it smaller dynamically
> while in use depending on the limits on the other node. That's really
> bad for stacking. So, yes, DRBD caused that issue. No other driver does
> it like this. A DRBD update can have caused that issue.

Uhm, no.

IF drbd would have made the max bio size smaller while being in use,
there would have been a log message like

 ASSERT FAILED new < now; (xyz < XYZ)
 max BIO size = NEW SIZE

Lutz, you see that in your kernel logs?

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list   --   I'm subscribed



More information about the drbd-user mailing list