All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: "Verma, Vishal L" <vishal.l.verma@intel.com>
Cc: "jmoyer@redhat.com" <jmoyer@redhat.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"axboe@fb.com" <axboe@fb.com>,
	"linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>,
	"neilb@suse.com" <neilb@suse.com>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: [PATCH 2/3] block: Add badblock management for gendisks
Date: Tue, 24 Nov 2015 13:31:58 -0800	[thread overview]
Message-ID: <CAPcyv4g13_6mS5uApb+3QUaGEf8630Znv3sq-2WrGiK5fKBs8Q@mail.gmail.com> (raw)
In-Reply-To: <1448395840.14996.8.camel@intel.com>

On Tue, Nov 24, 2015 at 12:10 PM, Verma, Vishal L
<vishal.l.verma@intel.com> wrote:
> On Tue, 2015-11-24 at 14:14 -0500, Jeff Moyer wrote:
>>
>> I'm not sure whether it makes sense to continue without badblock
>> management for the RAID code.  I was hoping Neil would comment on
>> that.
>>
>> -Jeff
>
> Not sure I follow? I believe I've kept all the badblocks functionality
> RAID already had..
>
>
> On a related note, something I observed when testing with md:
>
> md's badblock list is per-device, and can be seen at:
>         /sys/block/md0/md/dev-pmem0/bad_blocks
>
> Now if we have badblocks in the gendisks too, there is also:
>         /sys/block/pmem0/bad_blocks
>
> The two are separate 'accounts' maintained by separate drivers (md for
> the former, and pmem for the latter). This can potentially be
> confusing..
>
> Should we consolidate the two, i.e. make md (re)use the gendisk
> badblocks for its purposes too?

If we get agreement that tracking bad blocks at the gendisk is useful
for more than just nvdimms then yes, I think it makes sense to move md
bad_blocks to the gendisk layer.  That is provided we can add a
symlink to make the move transparent to existing md userspace tooling.

The use cases I can envision being useful for other disks is:

1/ Bypassing / avoiding known bad blocks on disks / drivers that
inject long completion latency for error handling.

2/ Simulating bad blocks for disks that can't store them locally.
Similar to the md use case, if one encounters errors restoring a disk
image from a backup it's useful to have the option to record the error
in a bad block list and keep going.

  reply	other threads:[~2015-11-24 21:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-21  0:49 [PATCH 0/3] Badblock tracking for gendisks Vishal Verma
2015-11-21  0:49 ` [PATCH 1/3] badblocks: Add core badblock management code Vishal Verma
2015-11-24 19:19   ` Jens Axboe
2015-11-21  0:49 ` [PATCH 2/3] block: Add badblock management for gendisks Vishal Verma
2015-11-24 15:34   ` Jeff Moyer
2015-11-24 19:03     ` Verma, Vishal L
2015-11-24 19:14       ` Jeff Moyer
2015-11-24 20:10         ` Verma, Vishal L
2015-11-24 21:31           ` Dan Williams [this message]
2015-11-25 15:37           ` Jeff Moyer
2015-11-25 17:55             ` Verma, Vishal L
2015-11-25 18:07               ` Jeff Moyer
2015-11-21  0:49 ` [PATCH 3/3] md: convert to use the generic badblocks code Vishal Verma

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=CAPcyv4g13_6mS5uApb+3QUaGEf8630Znv3sq-2WrGiK5fKBs8Q@mail.gmail.com \
    --to=dan.j.williams@intel.com \
    --cc=axboe@fb.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=neilb@suse.com \
    --cc=vishal.l.verma@intel.com \
    /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.