From: Keith Busch
On Fri, Dec 02, 2022 at 08:16:30AM +0100, Hannes Reinecke wrote:

quoted

On 12/1/22 20:39, Matthew Wilcox wrote:

quoted

On Thu, Dec 01, 2022 at 06:12:46PM +0000, Chaitanya Kulkarni wrote:

quoted

So nobody can get away with a lie.

And yet devices do exist which lie.  I'm not surprised that vendors
vehemently claim that they don't, or "nobody would get away with it".
But, of course, they do.  And there's no way for us to find out if
they're lying!

My guess, if true, is it's rationalized with the device is already
doing patrols in the background - why verify when it's already
been recently patrolled?
 

quoted

quoted

But we'll never be able to figure that out unless we try.

Once we've tried we will have proof either way.

As long as the protocols don't provide proof-of-work, trying this
doesn't really prove anything with respect to this concern.

I'm out of my depth here, but isn't VERIFY tightly related to PI and
at the heart of detecting SAN bit-rot? The proof of work can be via
end-to-end data protection. VERIFY has to actually read to detect bad
host generated PI guard/tags.  I'm assuming the PI checks can be
disabled for WRITE and enabled for VERIFY as the test.