Add forceNVME flag

[ixhamza]

NVMe devices are detected through the nvme prefix, which can be unreliable and require explicit specification. For one of our use cases, we have nvme ioctl compatible devices show up under names outside of /dev/nvme* .The ability to override disk type is already available for ata and scsi within openseachest. smartctl also has an option to force the NVMe protocol using smartctl -d nvme /dev/sdX, so it would be nice to have the same flag for NVMe devices in openSeaChest, similar to other protocols.

[vonericsen]

Hi @ixhamza,

Thanks for this pull request!
This seems reasonable to add, but will review it more in depth today.

Are you able to tell me more about the hardware or system configuration that causes these devices to show up under /dev/sdX (or whatever the handle is)?
We try to support auto-detection of something like this so that the users don't need to manually add this flag unless autodetection failed for some reason to keep things as easy as possible.
If I can get some more information about this configuration or how to create a similar test scenario internally, I will also look into auto-detecting when this is happening in a system.

[ixhamza]

Hello @vonericsen,

The NVMe device in question is connected to a trimode HBA, resulting in NVMe appearing as a SCSI LUN. We are utilizing the SCSI Host ioctl interface to directly send NVMe encapsulated commands to the firmware through a specially modified hba driver. This enables user space monitoring tools to send NVMe commands to the disk. Auto-detection would not be helpful here, as the disk can be accessed either through SCSI commands or NVMe commands.

[vonericsen]

@ixhamza,

Thank you for the additional information!
That is a really interesting configuration I had not heard of before.

If at any point you think having some auto-detection would be helpful in this setup we can work on something at that time. I've handled similar situations in the past where it can be good to pass either set of commands to the device and that is similar to how the SATA support in our tool works today.

I've gone ahead and merged this to our develop branch since it all looked good from my perspective. Thanks again!