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