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@xxxxxxx +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
