Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Jun 06, 2013 at 03:39:19PM +0200, Sebastian Riemer wrote: > On 04.06.2013 11:56, Lutz Vieweg wrote: > [...] > > What concerns me is that after the resizing, /var/log/messages > > accumulated a few dozen of these messages (only on the primary): > >> Jun 4 10:56:40 kernel: bio too big device drbd0 (304 > 256) > >> Jun 4 10:56:40 kernel: bio too big device drbd0 (264 > 256) > >> Jun 4 10:56:40 kernel: bio too big device drbd0 (384 > 256) > >> Jun 4 10:56:42 kernel: bio too big device drbd0 (512 > 256) > >> Jun 4 10:57:05 kernel: bio too big device drbd0 (512 > 256) > >> Jun 4 11:12:07 kernel: bio too big device drbd0 (376 > 256) > > Looks like something in the IO stack above DRBD in the kernel doesn't > respect the IO size limits of DRBD. > > In kernel 3.3 the function "blk_set_stacking_limits()" has been > introduced to fix such issues. MD uses this function for example. Before > that MD used too small IO limits. > > Try these commands and repeat them for the devices above: > $ cat /sys/block/drbd0/queue/max_sectors_kb > $ cat /sys/block/drbd0/queue/max_hw_sectors_kb > > Should be 128 as DRBD has 128 KiB hashing functions and can't do bigger > IO because of that. The kernel internally calculates with 512 byte > sectors. So 256 sectors are 128 KiB. At some point you need to update your part of reality, too ;-) He is talking about DRBD 8.4, and there is no such limitation anymore. -- : 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