[DRBD-user] Oopses/timeouts on 0.7.5 with many big volumes

[Philipp Reisner]

> >Yes, I have changed SLEEPS_LONG from 60 to 120 Seconds with the 
> >drbd-0.7.6 release.
> >  
> >
> Ok fine. But that doesn't solve the problem in the long term does it ? 
> (if the sleep time has to be a function of storage size)

The execution time of "drbdsetup /dev/drbdX disk ..." command is not a
function of the storage size. It is a function of the AL-size parameter,
which has a maximum value. But unfotunately high IO load makes the
execution of the command a lot slower.

[...]
> >The BitMap needs 32kByte per 1 GB of storage (in your case ~157 MB) RAM.
> >This RAM needs to be mapped into the virtual address space of the kernel.
> >[If I remeber correctly] there are only 128MB virtual address space
> >available for this on an x86-highmem kernel.
> >
> >Solution1: Get a 64 bit architecture like AMD Opteron.
> >Solution2: Ask LINBIT to rewrite the BitMap code to use unmapped
> >           (highmem) pages.
> >[...]
>
> Well if I understand correctly, the vmalloc=<size> kernel parameter
> precisely allows to overcome that 128MB limit.
> That problem went away when using vmalloc=256MB, anyway.
> Is it another limitation that you're talking about ?
>

Oh, I did not know about the "vmalloc=<size>" kernel parameter. I thought it
is necessary to change a #define somwhere and to recompile ther kernel. 
Great! No, if vmalloc=<size> does the trick, then it does the trick :)

[...]