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

Lars Ellenberg lars.ellenberg at linbit.com
Fri Jun 7 23:21:36 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 02:42:32PM +0200, Lutz Vieweg wrote:
> On 06/07/2013 02:03 PM, Lars Ellenberg wrote:
> >>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?
> Yes! - Now that I explicitely searched for such an assertion,
> I found one amongst the many harmless drbd status messages,
> at the time when the secondary was re-connected after moving
> the disk, there:
> >19:56:12 kernel: d-con ResourceData: conn( StandAlone -> Unconnected )
> >19:56:12 kernel: d-con ResourceData: Starting receiver thread (from drbd_w_Resource [2877])
> >19:56:12 kernel: d-con ResourceData: receiver (re)started
> >19:56:12 kernel: d-con ResourceData: conn( Unconnected -> WFConnection )
> >19:56:13 kernel: d-con ResourceData: Handshake successful: Agreed network protocol version 101
> >19:56:13 kernel: d-con ResourceData: conn( WFConnection -> WFReportParams )
> >19:56:13 kernel: d-con ResourceData: Starting asender thread (from drbd_r_Resource [19897])
> >19:56:13 kernel: block drbd0: ASSERT FAILED new < now; (131072 < 1048576)
> >19:56:13 kernel: block drbd0: max BIO size = 131072

"Should not happen"


Actually I think that since about 8.3.7 or 8.3.8,
the peer is well able to deal with "too big" incoming requests
by "spreading" them over multiple bios.

So that part of limit "adjustment" code
should depend on the respective protocol version
for comat reasons only.
We'll fix that.

I wonder why the peer has smaller max bio size in the first place, though.


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

More information about the drbd-user mailing list