On Wed, Aug 22, 2018 at 03:55:46PM +0200, Valentin Vidic wrote:
> DRBD end for this seems rather simple, it only checks if the
> device->open_cnt is zero. So it would seem like drbd_release
> was not called yet when the block-drbd script is run?
>
>
> static enum drbd_stat
On Wed, Aug 22, 2018 at 05:51:54PM +0200, Roger Pau Monné wrote:
> Can you add some debug prints to check if xen_blkif_disconnect is
> indeed returning EBUSY (or some error) and that's preventing the
> device from closing correctly?
These are production nodes, but I'll try that on some test machin
On Wed, Aug 22, 2018 at 06:23:01PM +0200, Valentin Vidic wrote:
> On Wed, Aug 22, 2018 at 05:51:54PM +0200, Roger Pau Monné wrote:
> > Can you add some debug prints to check if xen_blkif_disconnect is
> > indeed returning EBUSY (or some error) and that's preventing the
>
On Fri, Aug 24, 2018 at 06:22:32PM +0200, Valentin Vidic wrote:
> Managed to reproduce this and xen_blkif_disconnect is always returning 0
> like you expected. So this is some other issue, and from what I can tell
> blkdev_put of the underlying drbd device gets called some t
/etc/xen/scripts/block-drbd failed; error detected.
backend/vbd/6/51712/hotplug-status error to xenstore.
root: /etc/xen/scripts/block-drbd: /etc/xen/scripts/block-drbd failed; error
detected.
Signed-off-by: Valentin Vidic
Cc: sta...@vger.kernel.org
---
drivers/block/xen-blkback/xenbus.c | 2
On Wed, Aug 29, 2018 at 10:16:09AM +0200, Juergen Gross wrote:
> Did you test whether it is okay to not change state in case the device
> is still online?
Not sure how to simulate that. Maybe using xl block-detach or something else?
--
Valentin
___
Xe
On Wed, Aug 29, 2018 at 10:43:48AM +0200, Juergen Gross wrote:
> I think this should be an action triggered by the frontend, not by dom0
> (xen tools will always set "online" to 0 when removing a device, AFAIK).
>
> I'm not sure this is relevant, but I realized this behavior is changed
> by your p
On Wed, Sep 05, 2018 at 12:36:49PM +0200, Roger Pau Monné wrote:
> On Wed, Aug 29, 2018 at 08:52:14AM +0200, Valentin Vidic wrote:
> > Switching to closed state earlier can cause the block-drbd
> > script to fail with 'Device is held open by someone':
> >
> &
On Wed, Sep 05, 2018 at 01:35:15PM +0200, Valentin Vidic wrote:
> > AFAICT, this will cause the backend to never switch to 'Closed' state
> > until the toolstack sets online to 0, which is not good IMO.
> >
> > If for example a frontend decides to close a de
On Thu, Sep 06, 2018 at 06:14:21PM +0200, Roger Pau Monné wrote:
> On Wed, Sep 05, 2018 at 06:27:56PM +0200, Valentin Vidic wrote:
> > On Wed, Sep 05, 2018 at 12:36:49PM +0200, Roger Pau Monné wrote:
> > > On Wed, Aug 29, 2018 at 08:52:14AM +0200, Valentin Vidic wrote:
> >
On Thu, Sep 06, 2018 at 06:29:32PM +0200, Roger Pau Monné wrote:
> On Wed, Sep 05, 2018 at 06:28:01PM +0200, Valentin Vidic wrote:
> > On Wed, Sep 05, 2018 at 01:35:15PM +0200, Valentin Vidic wrote:
> > > > AFAICT, this will cause the backend to never switch to 'Close
On Fri, Sep 07, 2018 at 09:15:30AM +0200, Roger Pau Monné wrote:
> I'm not sure that's a good idea, there are a lot of backends (apart
> from blkback), and the tools won't know whether a specific backend
> supports such state or not. Also the current protocol and states are
> shared between all the
On Fri, Sep 07, 2018 at 09:54:55AM +0200, Roger Pau Monné wrote:
> Then I'm afraid you will have to look into the vbd_free/create fix.
Yes, here is a first draft for that idea, let me know if you see some
problems there:
--- xenbus.c.orig 2018-09-07 12:11:57.798071485 +0200
+++ xenbus.c
On Fri, Sep 07, 2018 at 12:43:09PM +0200, Roger Pau Monné wrote:
> I would prefer if you could avoid open-coding this here, and instead
> use xen_vbd_create or similar. I would also prefer that the call to
> xen_vbd_create in backend_changed was removed and we had a single call
> to xen_vbd_create
On Fri, Sep 07, 2018 at 02:03:37PM +0200, Lars Ellenberg wrote:
> Very frequently it is *NOT* the "original user", that "still" holds it
> open, but udev, or something triggered-by-udev.
>
> So double-checking the udev rules,
> or the "lvm global_filter" settings may help.
> You could instrument D
On Fri, Sep 07, 2018 at 03:28:28PM +0200, Lars Ellenberg wrote:
> We don't expose that, no.
> But even if we did, that would not be racefree :-)
>
> The last (or even: any?) "close" of a block device that used to be open
> for WRITE triggeres a udev "change" event, thus a udev run,
> and the minim
On Fri, Sep 07, 2018 at 06:45:00PM +0200, Valentin Vidic wrote:
> Adding a dump_stack in drbd_release gives two possible code paths,
> both from xen_blkback and the first one from workqueue being the
> problematic one:
In fact the first one is the original code path before I modifie
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
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
> >
On Mon, Sep 10, 2018 at 05:00:58PM +0200, Roger Pau Monné wrote:
> 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.
Thanks, I have two test no
On Thu, Sep 13, 2018 at 05:08:00PM +0200, Roger Pau Monné wrote:
> So I have the following patch which I think might solve your issues
> while keeping the reset logic working. Would you mind giving it a try
> with your use case and pvgrub?
Thanks for the patch. It seems to be having some problems
21 matches
Mail list logo
