linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>
Cc: "neilb@suse.com" <neilb@suse.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"jmoyer@redhat.com" <jmoyer@redhat.com>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"axboe@fb.com" <axboe@fb.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	"James.Bottomley@hansenpartnership.com"
	<James.Bottomley@hansenpartnership.com>
Subject: Re: [PATCH v2 1/3] badblocks: Add core badblock management code
Date: Tue, 8 Dec 2015 23:47:57 +0000	[thread overview]
Message-ID: <1449618477.16905.126.camel@intel.com> (raw)
In-Reply-To: <CAPcyv4gJrdP23sh2cQU94fpq6+Z9GBjxWf0RpBp_4+kydpQAsA@mail.gmail.com>

On Tue, 2015-12-08 at 13:18 -0800, Dan Williams wrote:
> On Tue, Dec 8, 2015 at 1:08 PM, Verma, Vishal L
> <vishal.l.verma@intel.com> wrote:
> > On Wed, 2015-12-09 at 08:03 +1100, NeilBrown wrote:
> > > On Sat, Dec 05 2015, Verma, Vishal L wrote:
> > > > > 
> > > > > > +int badblocks_clear(struct badblocks *bb, sector_t s, int
> > > > > > sectors)
> > > > > > +{
> > > > > [...]
> > > > > > +#define DO_DEBUG 1
> > > > > 
> > > > > Why have this at all if it's unconditionally defined and
> > > > > always
> > > > > set.
> > > > 
> > > > Neil - any reason or anything you had in mind for this? Or is it
> > > > just an
> > > > artifact and can be removed.
> > > 
> > > Like the comment says:
> > > 
> > >       /* Allow clearing via sysfs *only* for testing/debugging.
> > >        * Normally only a successful write may clear a badblock
> > >        */
> > > 
> > > The DO_DEBUG define and ifdefs are documentation identifying bits
> > > of
> > > code that should be removed when it all seems to be working.
> > > Maybe now is a good time to remove that code.
> > > 
> > Hm, I think it would be nice to continue to have the ability to
> > clear
> > badblocks using sysfs at least for a while more, as we test the
> > various
> > error handling paths for NVDIMMS (Dan, thoughts?).
> > 
> > We could either remove it later or (I'm leaning towards) make it a
> > config option similar to FAIL_MAKE_REQUEST and friends..
> 
> "later" as in before v4.5-rc1?  We can always carry this debug feature
> locally for testing.  We don't want userspace growing ABI attachments
> to this capability now that it's more than just md tooling that will
> see this.


Agreed. The following incremental patch removes sysfs support.
All the latest badblocks patches can also be found at:

git://git.kernel.org/pub/scm/linux/kernel/git/vishal/nvdimm.git gendisk-badblocks


8<-----
From 5f0e7ac31d27a132f314106f1db33af22fde03ed Mon Sep 17 00:00:00 2001
From: Vishal Verma <vishal.l.verma@intel.com>
Date: Tue, 8 Dec 2015 16:28:31 -0700
Subject: [PATCH v4 4/3] badblocks: remove support for clearing via sysfs

sysfs support for clearing badblocks was originally meant for testing
only. With the move to generalize the interface, remove this support so
that userspace doesn't start treating this as an ABI.

Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
 block/badblocks.c | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/block/badblocks.c b/block/badblocks.c
index f0ac279..e5d2a91 100644
--- a/block/badblocks.c
+++ b/block/badblocks.c
@@ -503,16 +503,6 @@ ssize_t badblocks_store(struct badblocks *bb, const
char *page, size_t len,
 	int length;
 	char newline;
 
-	/* Allow clearing via sysfs *only* for testing/debugging.
-	 * Normally only a successful write may clear a badblock
-	 */
-	int clear = 0;
-
-	if (page[0] == '-') {
-		clear = 1;
-		page++;
-	}
-
 	switch (sscanf(page, "%llu %d%c", &sector, &length, &newline))
{
 	case 3:
 		if (newline != '\n')
@@ -525,11 +515,6 @@ ssize_t badblocks_store(struct badblocks *bb, const
char *page, size_t len,
 		return -EINVAL;
 	}
 
-	if (clear) {
-		badblocks_clear(bb, sector, length);
-		return len;
-	}
-
 	if (badblocks_set(bb, sector, length, !unack))
 		return -ENOSPC;
 	else
-- 
2.5.0

  reply	other threads:[~2015-12-08 23:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-25 18:43 [PATCH v2 0/3] Badblock tracking for gendisks Vishal Verma
2015-11-25 18:43 ` [PATCH v2 1/3] badblocks: Add core badblock management code Vishal Verma
2015-12-04 23:30   ` James Bottomley
2015-12-04 23:58     ` Verma, Vishal L
2015-12-05  0:06       ` James Bottomley
2015-12-05  0:11         ` Verma, Vishal L
2015-12-08 21:03       ` NeilBrown
2015-12-08 21:08         ` Verma, Vishal L
2015-12-08 21:18           ` Dan Williams
2015-12-08 23:47             ` Verma, Vishal L [this message]
2015-12-22  5:34       ` NeilBrown
2015-12-22 22:13         ` Verma, Vishal L
2015-12-22 23:06           ` NeilBrown
2015-12-23  0:38             ` Verma, Vishal L
2015-11-25 18:43 ` [PATCH v2 2/3] block: Add badblock management for gendisks Vishal Verma
2015-12-04 23:33   ` James Bottomley
2015-12-05  0:17     ` Verma, Vishal L
2015-11-25 18:43 ` [PATCH v2 3/3] md: convert to use the generic badblocks code Vishal Verma
2015-12-01 18:55   ` Shaohua Li
2015-12-01 19:52     ` Verma, Vishal L
2015-12-04 22:53 ` [PATCH v2 0/3] Badblock tracking for gendisks Verma, Vishal L
  -- strict thread matches above, loose matches on Subject: below --
2015-12-08  2:52 Vishal Verma
2015-12-08  2:52 ` [PATCH v2 1/3] badblocks: Add core badblock management 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=1449618477.16905.126.camel@intel.com \
    --to=vishal.l.verma@intel.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=axboe@fb.com \
    --cc=dan.j.williams@intel.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=neilb@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).