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. Verify command for NVMe has significant impact when it comes to doing the maintenance work in downtime, that can get in a way when device is under heavy workload e.g. social media website being active at peak hours or high performance trading hours. In such a scenario controller doing the maintenance work can increase the tail latency of the workload and one can see spikes as SSD starts aging, this is also true for the file systems and databases when complex queries generating complex I/O patterns under a heavy I/Os. I respect your experience but calling every single SSD and enterprise grade SSD vendor a liar is just not true, as with enterprise SSD qualification process is extremely detailed oriented and each feature command gets excruciating design review including performance/watt. So nobody can get away with a lie. This patch-series has an option to emulate the verify operation, if you or someone don't want to trust the device one can simply turn off the verify command and let the kernel emulate the Verify, that will also save ton of the bandwidth especially in the case of fabrics and if it is not there I'll make sure to have in the final version. > Even expensive devices where there's an ironclad legal contract between > the vendor and customer may have bugs that result in only some of the > bytes being VERIFYed. We shouldn't support it. > One cannot simply write anything without bugs, see how many quirks we have for the NVMe PCIe SSDs that doesn't stop us supporting features in kernel if one can't trust the device just add a quirk and emulate. The bugs doesn't make this feature useless or design of the verify command unusable. There is a significant reason why it exists in major device specs based on which data-center workloads are running, just because there are few cheap vendors not being authentic we cannot call multiple TWG's decision to add verify command useless and not add support. In fact all the file systems should be sending verify command as a part of scrubbing which XFS only does as far as I know since lack of interface is preventing the use. > Now, everything you say about its value (not consuming bus bandwidth) > is true, but the device should provide the host with proof-of-work. > I'd suggest calculating some kind of checksum, even something like a > SHA-1 of the contents would be worth having. It doesn't need to be > crypto-secure; just something the host can verify the device didn't spoof. I'm not sure how SSD vendor will entertain the proof of work idea since it will open the door for other questions such as discard and any other commands since one of the blatant answer I got "if you don't trust don't buy". I'm absolutely not discarding your concerns and idea of proof of work, I'm wiling to work with you in the TWG and submit the proposal offline, but right now there is no support for this with existing specs. -ck
