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.