Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> >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 :) [...]