[DRBD-user] Oopses/timeouts on 0.7.5 with many big volumes
renaud.guerin at wanadooportails.com
Tue Nov 30 12:06:37 CET 2004
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
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
>...and switch to drbd-0.7.6
I will try it now with 0.7.6 and kernel 2.6.10-rc2
More information about the drbd-user