> I don't see any change in what's reported with block/for-next in a
> regular SCSI HBA/disk setup. Will have to look at whether there is a
> stacking issue wrt. multipathing.
Hi Martin, Christoph,
It seems this change in behaviour is not limited to SCSI only. As Nikhil
mentioned an earlier commit
[9f4aa46f2a74 ("block: invert the BLK_INTEGRITY_{GENERATE,VERIFY} flags")]
causes this change in behaviour. On my setup with a NVMe drive not formatted
with PI, I see that:
Without this commit:
Value reported by read_verify and write_generate sysfs entries is 0.
With this commit:
Value reported by read_verify and write_generate sysfs entries is 1.
Diving a bit deeper, both these flags got inverted due to this commit.
But during init (in nvme_init_integrity) these values get initialized to 0,
inturn setting the sysfs entries to 1. In order to fix this, the driver has to
initialize both these flags to 1 in nvme_init_integrity if PI is not supported.
That way, the value in sysfs for these entries would become 0 again. Tried this
approach in my setup, and I am able to see the right values now. Then something
like this would also need to be done for SCSI too.
