Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Is there a good formula for calulating a MetaData partition? D> ----- Original Message ----- From: "Lars Ellenberg" <Lars.Ellenberg at linbit.com> To: <drbd-user at lists.linbit.com> Sent: Tuesday, April 19, 2005 3:01 PM Subject: Re: [DRBD-user] Resized the Raid.... >/ 2005-04-19 11:47:00 +0200 > \ Lars Ellenberg: >> / 2005-04-19 02:03:33 -0500 >> \ David A. Smith: >> > Needed to replace the Disks in a Raid. Total size ended up being >> > smaller....so when i try to RE Initialize the drives the drbdsetup >> > crashes on me. Im assuming there needs to be some sort of Cleaning of >> > what the System THINKS the drive should be? >> > >> > drbdsetup /dev/drbd0 disk /dev/md0 internal -1 >> > >> > >> > drbd0: BM resizing failed. Leaving size unchanged at size = 2556165888 >> > KB >> > drbd0: Assuming that all blocks are out of sync (aka FullSync) >> > drbd0: drbd_bm_set_all: (!(b && b->bm)) in >> > drivers/block/drbd/drbd_bitmap.c:553 >> > Call Trace: >> > .drbd_bm_set_all+0x1b4/0x1bc [drbd] >> > .drbd_ioctl_set_disk+0x824/0x8c4 [drbd] >> > .drbd_ioctl+0x10d4/0x1754 [drbd] >> > .blkdev_ioctl+0xd4/0xa1c >> > .block_ioctl+0x28/0x40 >> > .sys_ioctl+0x314/0x4dc >> > .compat_sys_ioctl+0x130/0x398 >> > syscall_exit+0x0/0x18 >> >> At that point, b and b->bm are pointers, b points to the bitmap struct, >> which contains some housekeeping fields and the bm member, which points >> to the actual bitmap. One of them (looking at the code path, obviously >> b->bm) is NULL, i.e. points nowhere. Which means somewhen we had >> not enough memory to allocate enough room for it. >> Which is an unlikely code path, and was not exercised much in testing. >> >> So you found a bug, which I thought we had fixed long ago. >> If there is not enough memory to allocate the bitmap, >> it bugs during drbdsetup disk. >> And it does not even give a useful error message. >> The BUG is easy to remove, but it would leave you with a drbd device > > in fact it does not BUG(), it only does "show_stack()", which is a > verbose debug output that just looks similar to a real kernel bug. > still, we should be able to deal with this situation more sensibly. > > as long as we don't know _why_ the allocation fails, > I think you can only try to request smaller device size, like this: > > # try 1T > drbdsetup /dev/drbd0 disk /dev/md0 internal -1 -d 1024G > # works? try 2T > drbdsetup /dev/drbd0 down > drbdsetup /dev/drbd0 disk /dev/md0 internal -1 -d 2048G > # works? try ... > etc, do a binary search for a working maximum size. > > btw, you should use external meta data, > think about seek time for meta data updates... > > hope that helps, > > Lars > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user