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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux