From: "hch@lst.de" <hch@lst.de>
To: Carlos Carvalho <carlos@fisica.ufpr.br>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
Clay Mayers <Clay.Mayers@kioxia.com>,
Keith Busch <kbusch@kernel.org>, Hannes Reinecke <hare@suse.de>,
Matthew Wilcox <willy@infradead.org>,
Chaitanya Kulkarni <chaitanyak@nvidia.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"djwong@kernel.org" <djwong@kernel.org>,
"hch@lst.de" <hch@lst.de>, "sagi@grimberg.me" <sagi@grimberg.me>,
"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
"javier@javigon.com" <javier@javigon.com>,
"johannes.thumshirn@wdc.com" <johannes.thumshirn@wdc.com>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"dongli.zhang@oracle.com" <dongli.zhang@oracle.com>,
"jefflexu@linux.alibaba.com" <jefflexu@linux.alibaba.com>,
"josef@toxicpanda.com" <josef@toxicpanda.com>,
"clm@fb.com" <clm@fb.com>, "dsterba@suse.com" <dsterba@suse.com>,
"jack@suse.com" <jack@suse.com>, "tytso@mit.edu" <tytso@mit.edu>,
"adilger.kernel@dilger.ca" <adilger.kernel@dilger.ca>,
"jlayton@kernel.org" <jlayton@kernel.org>,
"idryomov@gmail.com" <idryomov@gmail.com>,
"danil.kipnis@cloud.ionos.com" <danil.kipnis@cloud.ionos.com>,
"ebiggers@google.com" <ebiggers@google.com>,
"jinpu.wang@cloud.ionos.com" <jinpu.wang@cloud.ionos.com>
Subject: Re: [PATCH 0/6] block: add support for REQ_OP_VERIFY
Date: Mon, 12 Dec 2022 07:30:17 +0100 [thread overview]
Message-ID: <20221212063017.GA9290@lst.de> (raw)
In-Reply-To: <Y5SEWnNUpgKxOB/W@fisica.ufpr.br>
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.
next prev parent reply other threads:[~2022-12-12 6:30 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-30 9:14 [PATCH 0/6] block: add support for REQ_OP_VERIFY Chaitanya Kulkarni
2022-06-30 9:14 ` [PATCH 1/6] " Chaitanya Kulkarni
2022-06-30 16:18 ` Darrick J. Wong
2022-07-05 16:50 ` Chaitanya Kulkarni
2022-07-05 17:57 ` Darrick J. Wong
2022-07-06 1:32 ` Chaitanya Kulkarni
2022-07-05 8:34 ` Christoph Hellwig
2022-07-05 23:55 ` Chaitanya Kulkarni
2022-06-30 9:14 ` [PATCH 2/6] nvme: add support for the Verify command Chaitanya Kulkarni
2022-06-30 16:24 ` Keith Busch
2022-07-05 8:34 ` Christoph Hellwig
2022-07-05 23:56 ` Chaitanya Kulkarni
2022-06-30 9:14 ` [PATCH 3/6] nvmet: add Verify command support for bdev-ns Chaitanya Kulkarni
2022-06-30 9:14 ` [PATCH 4/6] nvmet: add Verify emulation " Chaitanya Kulkarni
2022-07-05 8:35 ` Christoph Hellwig
2022-07-06 0:00 ` Chaitanya Kulkarni
2022-06-30 9:14 ` [PATCH 5/6] nvmet: add verify emulation support for file-ns Chaitanya Kulkarni
2022-07-05 8:36 ` Christoph Hellwig
2022-07-06 0:06 ` Chaitanya Kulkarni
2022-06-30 9:14 ` [PATCH 6/6] null_blk: add REQ_OP_VERIFY support Chaitanya Kulkarni
2022-07-05 8:38 ` [PATCH 0/6] block: add support for REQ_OP_VERIFY Christoph Hellwig
2022-07-05 16:47 ` Chaitanya Kulkarni
2022-07-06 17:42 ` Matthew Wilcox
2022-07-13 9:14 ` Chaitanya Kulkarni
2022-07-13 9:36 ` Johannes Thumshirn
2022-07-13 12:17 ` Matthew Wilcox
2022-07-13 14:04 ` Keith Busch
2022-12-01 18:12 ` Chaitanya Kulkarni
2022-12-01 19:39 ` Matthew Wilcox
2022-12-02 7:16 ` Hannes Reinecke
2022-12-02 14:58 ` Keith Busch
2022-12-02 17:33 ` Clay Mayers
2022-12-02 18:58 ` Keith Busch
2022-12-09 4:52 ` Martin K. Petersen
2022-12-10 13:06 ` Carlos Carvalho
2022-12-12 6:30 ` hch [this message]
2022-12-03 4:19 ` Javier González
2022-12-04 20:29 ` Keith Busch
2022-12-08 20:06 ` Javier González
2022-12-08 20:02 ` Matthew Wilcox
2022-12-02 7:13 ` Hannes Reinecke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221212063017.GA9290@lst.de \
--to=hch@lst.de \
--cc=Clay.Mayers@kioxia.com \
--cc=adilger.kernel@dilger.ca \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=carlos@fisica.ufpr.br \
--cc=chaitanyak@nvidia.com \
--cc=clm@fb.com \
--cc=danil.kipnis@cloud.ionos.com \
--cc=djwong@kernel.org \
--cc=dongli.zhang@oracle.com \
--cc=dsterba@suse.com \
--cc=ebiggers@google.com \
--cc=hare@suse.de \
--cc=idryomov@gmail.com \
--cc=jack@suse.com \
--cc=javier@javigon.com \
--cc=jefflexu@linux.alibaba.com \
--cc=jejb@linux.ibm.com \
--cc=jinpu.wang@cloud.ionos.com \
--cc=jlayton@kernel.org \
--cc=johannes.thumshirn@wdc.com \
--cc=josef@toxicpanda.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-raid@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=sagi@grimberg.me \
--cc=tytso@mit.edu \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.