On Thu, Mar 15, 2018 at 12:48 AM, Mike Christie wrote:
> ...
>
> It looks like there is a bug.
>
> 1. A regression was added when I stopped killing the iscsi connection
> when the lock is taken away from us to handle a failback bug where it
> was causing ping ponging. That
On Wed, Mar 14, 2018 at 12:05 PM, Michael Christie <mchri...@redhat.com>
wrote:
> On 03/14/2018 01:27 PM, Michael Christie wrote:
>> > On 03/14/2018 01:24 PM, Maxim Patlasov wrote:
>> >> On Wed, Mar 14, 2018 at 11:13 AM, Jason Dillaman <jdill...@redhat.com
On Wed, Mar 14, 2018 at 12:05 PM, Michael Christie <mchri...@redhat.com>
wrote:
> On 03/14/2018 01:27 PM, Michael Christie wrote:
> > On 03/14/2018 01:24 PM, Maxim Patlasov wrote:
> >> On Wed, Mar 14, 2018 at 11:13 AM, Jason Dillaman <jdill...@redhat.com
> >>
On Wed, Mar 14, 2018 at 11:47 AM, Michael Christie
wrote:
>
> > ...
>
> Ignore all these questions. I'm pretty sure I know the issue.
>
>
Fine, but can you please also elaborate on:
> For this case it would be tcmu_rbd_handle_blacklisted_cmd
How does it tell kernel to
tcmu-runner, the lock is already reacquired and it
goes to OSD smoothly overwriting newer data.
>
> On Wed, Mar 14, 2018 at 2:06 PM, Maxim Patlasov <mpatla...@skytap.com>
> wrote:
> > On Sun, Mar 11, 2018 at 5:10 PM, Mike Christie <mchri...@redhat.com>
> wrote:
> >
On Sun, Mar 11, 2018 at 5:10 PM, Mike Christie wrote:
> On 03/11/2018 08:54 AM, shadow_lin wrote:
> > Hi Jason,
> > How the old target gateway is blacklisted? Is it a feature of the target
> > gateway(which can support active/passive multipath) should provide or is
> > it