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 06/06/2013 09:12 PM, Lars Ellenberg wrote:
umount, close crypt, down drbd, then start things up again.
Do the limits correctly stack then?
They did stack correctly after the reboot.
Regards,
Lutz Vieweg
___
drbd-user mailing list
drbd-user@lis
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 t
On 06/06/2013 09:12 PM, Lars Ellenberg wrote:
Short term workaround:
cat /sys/block/drbd0/queue/max_hw_sectors_kb >
/sys/block/dm-9/queue/max_sectors_kb
that is: limit max_sectors_kb (which is a tunable)
to the currently apparent limits of the lower stack.
That should stop new "too big" bios f
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
> >>
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 p
