Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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. Have a look into the kernel source in "block/blk-core.c" and search for "bio too big device" for details. In the function "generic_make_request_checks()" you can see that an IO error is sent to the upper layers in that case ( bio_endio(bio, -EIO) ). > The system does not yet show any abnormal behaviour, it has > been running busy for some days after the first of those messages > appeared. > 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. [...] Cheers, Sebastian