> From: Keith Busch > On Fri, Dec 02, 2022 at 08:16:30AM +0100, Hannes Reinecke wrote: > > On 12/1/22 20:39, Matthew Wilcox wrote: > > > On Thu, Dec 01, 2022 at 06:12:46PM +0000, Chaitanya Kulkarni wrote: > > > > 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? > > > > > 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.
