[DRBD-user] ASSERT( 0 ) in drbd_worker.c:541

[Lars Ellenberg]

Message-ID:  <PmkBOMyjlSmFOmHg9RoPvLw=lge at web.de>
Reply-To: 
In-Reply-To: <200407281606.29377.bernd-schubert at web.de>

/ 2004-07-28 16:06:26 +0200
\ Bernd Schubert:
> Hello,
> 
> after disconnecting and reconnecting one of our drbd devices became not synced 
> but was left in inconsistent state:
> 
> On the primary node we see this in the from dmesg (similar to the output from 
> the secondary node):
> 
> [snip]
> drbd2: Connection established.
> drbd3: Handshake successful: DRBD Protocol version 74
> drbd3: Connection established.
> drbd2: Primary/Unknown --> Primary/Secondary
> drbd3: Primary/Unknown --> Primary/Secondary
> drbd3: Resync started as SyncSource (need to sync 20 KB [5 bits set]).
> drbd2: Resync started as SyncSource (need to sync 1088284 KB [272071 bits 
> set]).
> drbd3: Syncer waits for sync group.
so it is PausedSyncS now...

> drbd4: Handshake successful: DRBD Protocol version 74
> drbd4: Connection established.
> drbd3: Resync done (total 1 sec; 20 K/sec)

--> see

> drbd3: ASSERT( 0 ) in drbd_worker.c:541
> drbd4: Primary/Unknown --> Primary/Secondary
> [snip]
> 
> The drbd-version is 0.7, kernel is 2.4.27-rc3.
> 
> Any ideas what this message means?

yes.
"unexpected cstate in drbd_resync_finished".
It is yet an other one of the buglets that are caused by overlooking
that "PausedSync*" are valid states, too.  By using set_in_sync with
proto 'C' for normal writes, too.  So it can happen that resync finished
because of applicatoni writes while this sync group was actually
paused...

can you reproduce it? did it happen more than once?

 ==> Philipp, we should grep for any ASSERT(0),
     and replace all of them with something more useful.
     and grep for all occurences of cstate in relational expressions,
     verify and comment on our expectations.


	Lars Ellenberg

-- 
please use the "List-Reply" function of your email client.