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 1A2FDC04FDE for ; Mon, 12 Dec 2022 06:30:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231326AbiLLGab (ORCPT ); Mon, 12 Dec 2022 01:30:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39618 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229697AbiLLGaa (ORCPT ); Mon, 12 Dec 2022 01:30:30 -0500 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E0E07B1EA; Sun, 11 Dec 2022 22:30:28 -0800 (PST) Received: by verein.lst.de (Postfix, from userid 2407) id 70C1268AA6; Mon, 12 Dec 2022 07:30:18 +0100 (CET) Date: Mon, 12 Dec 2022 07:30:17 +0100 From: "hch@lst.de" To: Carlos Carvalho Cc: "Martin K. Petersen" , Clay Mayers , Keith Busch , Hannes Reinecke , 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" , "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 Message-ID: <20221212063017.GA9290@lst.de> References: <20220630091406.19624-1-kch@nvidia.com> <72a51a83-c25a-ef52-55fb-2b73aec70305@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Sat, Dec 10, 2022 at 10:06:34AM -0300, Carlos Carvalho wrote: > Certainly we have. Currently admins have to periodically run full block range > checks in redundant arrays to detect bad blocks and correct them while > redundancy is available. Otherwise when a disk fails and you try to reconstruct > the replacement you hit another block in the remaining disks that's bad and you > cannot complete the reconstruction and have data loss. These checks are a > burden because they have HIGH overhead, significantly reducing bandwidth for > the normal use of the array. > > If there was a standard interface for getting the list of bad blocks that the > firmware secretly knows the kernel could implement the repair continuosly, with > logs etc. That'd really be a relief for admins and, specially, users. Both SCSI and NVMe can do this through the GET LBA STATUS command - in SCSI this was a later addition abusing the command, and in NVMe only the abuse survived. NVMe also has a log page an AEN associated for it, I'd have to spend more time reading SBC to remember if SCSI also has a notification mechanism of some sort.