From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CB8BC47088 for ; Fri, 2 Dec 2022 17:50:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234012AbiLBRui convert rfc822-to-8bit (ORCPT ); Fri, 2 Dec 2022 12:50:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233389AbiLBRuh (ORCPT ); Fri, 2 Dec 2022 12:50:37 -0500 X-Greylist: delayed 901 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Fri, 02 Dec 2022 09:50:36 PST Received: from SJSMAIL01.us.kioxia.com (usmailhost21.kioxia.com [12.0.68.226]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12167DEA79; Fri, 2 Dec 2022 09:50:36 -0800 (PST) Received: from SJSMAIL01.us.kioxia.com (10.90.133.90) by SJSMAIL01.us.kioxia.com (10.90.133.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Fri, 2 Dec 2022 09:33:33 -0800 Received: from SJSMAIL01.us.kioxia.com ([::1]) by SJSMAIL01.us.kioxia.com ([fe80::f5ad:7ba5:d6cc:6f21%3]) with mapi id 15.01.2375.034; Fri, 2 Dec 2022 09:33:33 -0800 From: Clay Mayers To: Keith Busch , Hannes Reinecke CC: Matthew Wilcox , Chaitanya Kulkarni , "linux-block@vger.kernel.org" , "linux-raid@vger.kernel.org" , "linux-nvme@lists.infradead.org" , "linux-fsdevel@vger.kernel.org" , "axboe@kernel.dk" , "djwong@kernel.org" , "hch@lst.de" , "sagi@grimberg.me" , "jejb@linux.ibm.com" , "martin.petersen@oracle.com" , "javier@javigon.com" , "johannes.thumshirn@wdc.com" , "bvanassche@acm.org" , "dongli.zhang@oracle.com" , "jefflexu@linux.alibaba.com" , "josef@toxicpanda.com" , "clm@fb.com" , "dsterba@suse.com" , "jack@suse.com" , "tytso@mit.edu" , "adilger.kernel@dilger.ca" , "jlayton@kernel.org" , "idryomov@gmail.com" , "danil.kipnis@cloud.ionos.com" , "ebiggers@google.com" , "jinpu.wang@cloud.ionos.com" Subject: RE: [PATCH 0/6] block: add support for REQ_OP_VERIFY Thread-Topic: [PATCH 0/6] block: add support for REQ_OP_VERIFY Thread-Index: AQHYjGHN/dRfjWV95kG4kItzDx62xa1xpq+AgOihlACAAJ5aAIAAwrsAgACBBAD//5Rf8A== Date: Fri, 2 Dec 2022 17:33:33 +0000 Message-ID: References: <20220630091406.19624-1-kch@nvidia.com> <72a51a83-c25a-ef52-55fb-2b73aec70305@suse.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.93.77.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org > 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.