From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Valentin Vidic <Valentin.Vidic@CARNet.hr>
Cc: <drbd-user@lists.linbit.com>, Jens Axboe <axboe@kernel.dk>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>,
<linux-block@vger.kernel.org>, <xen-devel@lists.xenproject.org>
Subject: Re: [DRBD-user] [PATCH] xen-blkback: Switch to closed state after releasing the backing device
Date: Mon, 10 Sep 2018 17:00:58 +0200 [thread overview]
Message-ID: <20180910150058.suxehc3uheyho4qx@mac.bytemobile.com> (raw)
In-Reply-To: <20180910132252.GE26705@gavran.carpriv.carnet.hr>
On Mon, Sep 10, 2018 at 03:22:52PM +0200, Valentin Vidic wrote:
> On Mon, Sep 10, 2018 at 02:45:31PM +0200, Lars Ellenberg wrote:
> > On Sat, Sep 08, 2018 at 09:34:32AM +0200, Valentin Vidic wrote:
> > > On Fri, Sep 07, 2018 at 07:14:59PM +0200, Valentin Vidic wrote:
> > > > In fact the first one is the original code path before I modified
> > > > blkback. The problem is it gets executed async from workqueue so
> > > > it might not always run before the call to drbdadm secondary.
> > >
> > > As the DRBD device gets released only when the last IO request
> > > has finished, I found a way to check and wait for this in the
> > > block-drbd script:
> >
> > > --- block-drbd.orig 2018-09-08 09:07:23.499648515 +0200
> > > +++ block-drbd 2018-09-08 09:28:12.892193649 +0200
> > > @@ -230,6 +230,24 @@
> > > and so cannot be mounted ${m2}${when}."
> > > }
> > >
> > > +wait_for_inflight()
> > > +{
> > > + local dev="$1"
> > > + local inflight="/sys/block/${dev#/dev/}/inflight"
> > > + local rd wr
> > > +
> > > + if ! [ -f "$inflight" ]; then
> > > + return
> > > + fi
> > > +
> > > + while true; do
> > > + read rd wr < $inflight
> > > + if [ "$rd" = "0" -a "$wr" = "0" ]; then
> >
> > If it is "idle" now, but still "open",
> > this will not sleep, and still fail the demotion below.
>
> True, but in this case blkback is holding it open until all
> the writes have finished and the last write closes the device.
> Since fuser can't check blkback this is an approximation that
> seems to work because I don't get any failed drbdadm calls now.
>
> > You try to help it by "waiting forever until it appears to be idle".
> > I suggest to at least limit the retries by iteration or time.
> > And also (or, instead; but you'd potentially get a number of
> > "scary messages" in the logs) add something like:
>
> Ok, should I open a PR to discuss this change further?
>
> > Or, well, yes, fix blkback to not "defer" the final close "too long",
> > if at all possible.
>
> blkback needs to finish the writes on shutdown or I get a fsck errors
> on next boot. Ideally XenbusStateClosed should be delayed until the
> device release but currently it does not seem possible without breaking
> other things.
I can try to take a look at this and attempt to make sure the state is
only changed to closed in blkback _after_ the device has been
released, but it might take me a couple of days to get you a patch.
I'm afraid that other hotplug scripts will also have issues with such
behavior, and we shouldn't force all users of hotplug scripts to add
such workarounds.
Roger.
next prev parent reply other threads:[~2018-09-10 15:01 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-29 6:52 [PATCH] xen-blkback: Switch to closed state after releasing the backing device Valentin Vidic
2018-08-29 8:16 ` Juergen Gross
2018-08-29 8:27 ` Valentin Vidic
2018-08-29 8:43 ` Juergen Gross
2018-08-29 9:23 ` Valentin Vidic
2018-08-29 9:29 ` Juergen Gross
2018-09-05 10:36 ` Roger Pau Monné
2018-09-05 16:27 ` Valentin Vidic
2018-09-06 16:14 ` Roger Pau Monné
2018-09-06 22:03 ` Valentin Vidic
2018-09-07 12:03 ` [DRBD-user] " Lars Ellenberg
2018-09-07 12:13 ` Valentin Vidic
2018-09-07 13:28 ` Lars Ellenberg
2018-09-07 16:45 ` Valentin Vidic
2018-09-07 17:14 ` Valentin Vidic
2018-09-08 7:34 ` Valentin Vidic
2018-09-10 12:45 ` Lars Ellenberg
2018-09-10 13:22 ` Valentin Vidic
2018-09-10 15:00 ` Roger Pau Monné [this message]
2018-09-10 16:18 ` Valentin Vidic
2018-09-13 15:08 ` Roger Pau Monné
2018-09-14 11:49 ` Valentin Vidic
2018-09-14 16:18 ` Roger Pau Monné
[not found] ` <20180905113515.GU26705@gavran.carpriv.carnet.hr>
2018-09-05 16:28 ` Valentin Vidic
2018-09-06 16:29 ` Roger Pau Monné
2018-09-06 22:19 ` Valentin Vidic
2018-09-07 7:15 ` Roger Pau Monné
2018-09-07 7:23 ` Valentin Vidic
2018-09-07 7:54 ` Roger Pau Monné
2018-09-07 10:20 ` Valentin Vidic
2018-09-07 10:43 ` Roger Pau Monné
2018-09-07 11:15 ` Valentin Vidic
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=20180910150058.suxehc3uheyho4qx@mac.bytemobile.com \
--to=roger.pau@citrix.com \
--cc=Valentin.Vidic@CARNet.hr \
--cc=axboe@kernel.dk \
--cc=drbd-user@lists.linbit.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).