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 _______________________________________________ drbd-user mailing list drbd-user@lists.linbit.com http://lists.linbit.com/mailman/listinfo/drbd-user
