[PATCH 0/6] block: add support for REQ_OP_VERIFY

[Hannes Reinecke]

On 12/1/22 19:12, Chaitanya Kulkarni wrote:
> On 7/6/22 10:42, Matthew Wilcox wrote:
>> On Thu, Jun 30, 2022 at 02:14:00AM -0700, Chaitanya Kulkarni wrote:
>>> This adds support for the REQ_OP_VERIFY. In this version we add
>>
>> IMO, VERIFY is a useless command.  The history of storage is full of
>> devices which simply lie.  Since there's no way for the host to check if
>> the device did any work, cheap devices may simply implement it as a NOOP.
> 
> In past few months at various storage conferences I've talked to
> different people to address your comment where device being
> a liar verify implementation or even implementing NOOP.
> 
> With all do respect this is not true.
> 
[ .. ]

Be careful to not fall into the copy-offload trap.
The arguments given do pretty much mirror the discussion we had during 
designing and implementing copy offload.

Turns out that the major benefit for any of these 'advanced' commands is 
not so much functionality but rather performance.
If the functionality provided by the command is _slower_ as when the 
host would be doing is manually there hardly is a point even calling 
that functionality; we've learned that the hard way with copy offload, 
and I guess the same it true for 'verify'.
Thing is, none of the command will _tell_ you how long that command will 
take; you just have to issue it and wait for it to complete.
(Remember TRIM? And device which took minutes to complete it?)

For copy offload we only recently added a bit telling the application 
whether it's worth calling it, or if we should rather do it the old 
fashioned way.

But all of the above discussion has nothing to do with the 
implementation. Why should we disallow an implementation for a 
functionality which is present in hardware?
How could we figure out the actual usability if we don't test?
Where is the innovation?

We need room for experimenting; if it turns out to be useless we can 
always disable or remove it later. But we shouldn't bar implementations 
because hardware _might_ be faulty.

I do see at least two topics for the next LSF:

- Implementation of REQ_OP_VERIFY
- Innovation rules for the kernel
...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare at suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman