[DRBD-user] Oops when shutting down drbd
sabelka at iue.tuwien.ac.at
Wed Aug 1 10:16:35 CEST 2007
thanks for your answer!
On Tuesday 31 July 2007 22:10, Lars Ellenberg wrote:
> On Tue, Jul 31, 2007 at 05:58:09PM +0200, Rainer Sabelka wrote:
> > Jul 30 14:57:40 newserver2 kernel: drbd0: drbd_bm_resize:
> > (down_trylock(&b->bm_change)) in
> > /usr/src/modules/drbd/drbd/drbd_bitmap.c:370 Jul 30 14:57:40 newserver2
> > kernel: drbd0: drbd_bm_resize called with capacity == 1409178656
> so you do have ~ 1.4 TB of storage.
No. The partition I use for DRBD has 704610868 kB, so this apoprox. the half.
> > [...]
> it may be that you see two problems:
> first, some race condition accessing the bitmap,
> second the debug aid that should help in finding the cause of the race
> condition dereferencing a NULL pointer in a debug printk...
> and that NULL pointer would be the mdev->bitmap,
> compare with drbd_bitmap.c ~ line 780 (drbd_bm_rw)...
> and the printk in the __drbd_bm_lock function...
Hmmm... with printk you mean the line
ERR("%s:%d: bitmap already locked by %s:%lu\n",
file, line, b->bm_file,b->bm_line);
If b (=mdev->bitmap) is NULL here, then the crash would be before calling
printk(), wouldn't it?
Could it be that b->bm_file is NULL?
> if this is actually the case, we need to track down and fix the cause of
> the race condition. as a work around for now, I'd recommend to add some
> "sleep 1" statements between your "multiple drbd related operations",
> and maybe even between the various drbdadm calls in the drbd init script.
Yes, I'll try this. (I've never had this problem when executing drbdadm
commnds directly from the commandline, only when doing multiple commands in a
script - so this may indeed be due to a race condition).
I'll let you know when I'm seeing this again - hopefully then I can give you
more information than just a kernel call trace.
> > 2nd incident:
> > [...]
> this one should be fixed with svn revision 2964.
> please try again with current
Thanks for your help!
More information about the drbd-user