From: Lars Ellenberg <lars.ellenberg@linbit.com>
To: drbd-dev@lists.linbit.com
Subject: Re: [Drbd-dev] Barrier assert failures with latest 8.0 sources
Date: Tue, 22 Jan 2008 17:20:07 +0100 [thread overview]
Message-ID: <20080122162007.GD7594@barkeeper1.linbit> (raw)
In-Reply-To: <342BAC0A5467384983B586A6B0B3767107E89D34@EXNA.corp.stratus.com>
On Mon, Jan 21, 2008 at 09:29:02PM -0500, Graham, Simon wrote:
> > > I'm not sure why tl_clear leaves this pseudo-barrier in the list...
> > > shouldn't it simply leave the list completely empty just like
> tl_init
> > > does?
> >
> > probably.
> > we have seen these ASSERTS, too, btw, also without this latest change
> > in
> > the barrier code, so aparently it has been there all along.
> > unfortunately we are all sort of distracted right now.
> > but coding will resume shortly :)
>
> Well, I realize now that I completely misunderstood again;
> newest_barrier represents thenext barrier that will be sent, so of
> course there has to be one in the list at all times (and tl_init also
> sets up barrier 4711).
>
> I think the problem is that tl_clear does NOT clear the CREATE_BARRIER
> bit from mdev->flags - so if we disconnect in the small window between
> setting this bit and creating the new barrier, then when we reconnect
> and send the first request, we'll end up creating a new barrier before
> sending the BarrierRq(4711) (processing the first request that has to go
> remote) and I think this gets us into the cycle of always being one
> barrier behind the remote system... this would also explain why the
> assert is intermittent since you have to disconnect in a small window...
>
> Seem reasonable?
absolutely.
:)
--
: Lars Ellenberg Tel +43-1-8178292-55 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Vivenotgasse 48, A-1120 Vienna/Europe http://www.linbit.com :
next prev parent reply other threads:[~2008-01-22 16:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-19 16:40 [Drbd-dev] Barrier assert failures with latest 8.0 sources Graham, Simon
2008-01-21 16:36 ` Lars Ellenberg
2008-01-22 2:29 ` Graham, Simon
2008-01-22 16:20 ` Lars Ellenberg [this message]
[not found] ` <342BAC0A5467384983B586A6B0B3767107E89D34@EXNA.corp.s tratus.com>
2008-01-22 20:49 ` Graham, Simon
2008-01-23 13:53 ` Graham, Simon
2008-01-23 14:03 ` Graham, Simon
-- strict thread matches above, loose matches on Subject: below --
2008-01-19 16:25 Graham, Simon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080122162007.GD7594@barkeeper1.linbit \
--to=lars.ellenberg@linbit.com \
--cc=drbd-dev@lists.linbit.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.