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

Renaud Guerin renaud.guerin at wanadooportails.com
Tue Nov 30 12:06:37 CET 2004

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

Philipp Reisner wrote:

>drbd-0.7.6 is known to compile on linux-2.6.10-rc2
Ok I hadn't seen 0.7.6 was out of CVS. I will try it out now

>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 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 ?

>>Problem 3 (most serious)
>>There's a new, more serious oops that happened on the target machine, a
>>few minutes after I finally started synchronisation:
>Have never seen this before... But will not trust anything as long as
>problem2 is not solved (at least reduce the number of volumes, so that
>there is enough LOWMEM to hold the BitMap for the volumes...)
same question as above : even with vmalloc=256M, could there still be a 
problem ?

>...and switch to drbd-0.7.6
I will try it now with 0.7.6 and kernel 2.6.10-rc2

Thank you.

More information about the drbd-user mailing list