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 time after
> xenbus_swit
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
> > device from closing corre
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 05:39:28PM +0200, Valentin Vidic wrote:
> 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-d
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_state_rv
> is_valid_state(st
