Switching to closed state earlier can cause the block-drbd
script to fail with 'Device is held open by someone':
root: /etc/xen/scripts/block-drbd: remove XENBUS_PATH=backend/vbd/6/51712
kernel: [ .278235] block drbd6: State change failed: Device is held open by
someone
kernel: [ .278304]
On 29/08/18 08:52, Valentin Vidic wrote:
> Switching to closed state earlier can cause the block-drbd
> script to fail with 'Device is held open by someone':
>
> root: /etc/xen/scripts/block-drbd: remove XENBUS_PATH=backend/vbd/6/51712
> kernel: [ .278235] block drbd6: State change failed: Dev
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 29/08/18 10:27, Valentin Vidic wrote:
> 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?
>
I think this
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 29/08/18 11:23, Valentin Vidic wrote:
> 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
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':
>
> root: /etc/xen/scripts/block-drbd: remove XENBUS_PATH=backend/vbd/6/51712
> kernel: [ .278235] block drbd6: S
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':
> >
> > root: /etc/xen/scripts/block-drbd: rem
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 device, the backend will
> > stay in state
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:
> > > Switching to closed state earlier can cause the block-drbd
> > > script to fail with 'Device i
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 'Closed' state
> > > until the toolstack sets online to 0, which is not good IMO.
> > >
> > > If for exampl
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:
> > > > Switching to closed s
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 'Closed' state
> > > > until the tool
On Fri, Sep 07, 2018 at 12:19:29AM +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 ca
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:23:19AM +0200, Valentin Vidic wrote:
> 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 o
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:20:26PM +0200, Valentin Vidic wrote:
> 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:
Th
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
19 matches
Mail list logo
