Re: [PATCH] nvme-multipath: do not reset controller on unknown status

[Sagi Grimberg <sagi@grimberg.me>]

>> What will happen in the common case? right now it will just retry
>> it on the same path, is that the desired behavior?
>>
>> I guess we need to understand the phenomenon better.
>>
>> Right now the code says, we don't know what went wrong here, so we
>> are going to reset the controller because it acts weird, which can
>> make some sense, given that the host doesn't understand what is going
>> on...
>>
> But this is precisely the case I'm arguing against here.
> One of the lessons learned from SCSI is that reset only makes sense if
> the system misbehaves and resetting it would make this error go away.
> 
> Receiving a status code which we don't know about does _not_ fall into
> this category; the very fact that we have a status code proves that the
> system does _not_ misbehave.

Fair enough...

> So what exactly will be resolved by resetting?
> There actually is a fair chance that we'll be getting the very same
> error again...

Or not, we don't know.. That is exactly the point.. But I agree with
you that resetting the controller may not the best action to take here.

But, you didn't answer my question, what is the expected behavior here?
right now with your patch is to blindly retry on the same path, is that
desired? is that always desired? Please share more details on the issue.

> Consequently I think that resetting the system here is wrong, and we
> should just handle it as a normal but unknown error.

What is this unknown error? Was it what John complained about a few
months back that the array returned a status code that translated
to BLK_STS_IOERR which is considered a path error and the host reset
the controller?

I think I'm starting to remember that this sort of approach was
suggested... I forget the details though...

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme