Re: [PATCH] multipath-tools: check sysfs path state for NVMe/NVMf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Merged.
Thanks.

On Fri, Jul 28, 2017 at 8:54 AM, Guan Junxiong <guanjunxiong@xxxxxxxxxx> wrote:
Hi Hannes,

On 2017/7/28 14:12, Hannes Reinecke wrote:
> On 07/28/2017 03:28 AM, Guan Junxiong wrote:
>> The previous code of path_offline checking was only valid for SCSI
>> device. It returned PATH_UP for other devices and throwed path check-
>> ing to chekers. This patch supplements checking sysfs path state for
>> NVMe/NVMf devices. For example, if NVMe/NVMf path is reconnectting or
>> resetting, we return PATH_PENDING in order to skip current path check-
>> ing and reschedule path checking in the next tick as soon as possible.
>>
>> Signed-off-by: Guan Junxiong <guanjunxiong@xxxxxxxxxx>
>> ---
>>  libmultipath/discovery.c | 45 +++++++++++++++++++++++++++++++++++----------
>>  1 file changed, 35 insertions(+), 10 deletions(-)
>>
> Thanks for doing this.
>
>>
> Patch looks good.
>
> Reviewed-by: Hannes Reinecke <hare@xxxxxxxx>
>
Nice to have any review. Thanks.

> However, I do wonder if we really need a path checker for NVMf once we
> have this. After all, the sysfs attribute reflects that KATO status,
> which pretty much determines if we can send I/O _at all_.
>
> Cheers,
>
> Hannes

IMO, I think Keep Alive feature is in controller granularity , _not_ namespace
granularity. A namespace can be detached ( or disabled with nvmetcli tools)
from controller which has many namespaces attached, but the controller sysfs
state attribute is still "live". Therefor, we do need further path checker
after we know controller is live.

Refer to the following quoted from NVMe Spec 1.3:
"The Keep Alive feature is used by the host to determine that the controller
is operational and by the controller to determine that the host is operational.
The host and controller are operational when each is accessible and able to
issue or execute commands."


Regards
Guan


.


--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux