Linux RAID subsystem development
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Brassow Jonathan <jbrassow@redhat.com>
Cc: "linux-raid@vger.kernel.org Raid" <linux-raid@vger.kernel.org>
Subject: Re: [PATCH] DM RAID: Explicitly turn off bad block support
Date: Tue, 23 Apr 2013 10:05:15 +1000	[thread overview]
Message-ID: <20130423100515.5c4c3ee6@notabene.brown> (raw)
In-Reply-To: <1EBA319B-13B9-4E75-A62F-C3F180A08C07@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

On Mon, 22 Apr 2013 11:29:48 -0500 Brassow Jonathan <jbrassow@redhat.com>
wrote:

> 
> On Apr 21, 2013, at 7:52 PM, NeilBrown wrote:
> 
> > On Fri, 19 Apr 2013 08:30:24 -0500 Jonathan Brassow <jbrassow@redhat.com>
> > wrote:
> > 
> >> DM RAID:  Explicitly turn off bad block support
> >> 
> >> DM RAID does not currently use the bad block tracking available in
> >> MD.  'badblocks.shift' must be set to '-1' in order to explicitly
> >> tell MD not to perform bad block related functions, like
> >> narrow_write_error().
> >> 
> >> Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
> >> 
> >> Index: linux-upstream/drivers/md/dm-raid.c
> >> ===================================================================
> >> --- linux-upstream.orig/drivers/md/dm-raid.c
> >> +++ linux-upstream/drivers/md/dm-raid.c
> >> @@ -170,8 +170,10 @@ static struct raid_set *context_alloc(st
> >> 	rs->md.delta_disks = 0;
> >> 	rs->md.recovery_cp = 0;
> >> 
> >> -	for (i = 0; i < raid_devs; i++)
> >> +	for (i = 0; i < raid_devs; i++) {
> >> 		md_rdev_init(&rs->dev[i].rdev);
> >> +		rs->dev[i].rdev.badblocks.shift = -1; /* No bad block support */
> >> +	}
> >> 
> >> 	/*
> >> 	 * Remaining items to be initialized by further RAID params:
> >> 
> > 
> > Thanks, but I don't think this is the right fix.
> > md_rdev_init really should set shift to -1, because we can only support
> > badblocks if the metadata explicitly supports it.
> > 
> > What do you think of this instead?
> 
> I like it much better.  It means that the proper initialization is done centrally, rather than expecting every super block type to know enough to turn off things they may not know about.  I considered this, but went along with the idea that it was the responsibility of the individual superblock handlers.
> 

:-)

Does this need to go to -stable?  Which versions, do you know?

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2013-04-23  0:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-19 13:30 [PATCH] DM RAID: Explicitly turn off bad block support Jonathan Brassow
2013-04-22  0:52 ` NeilBrown
2013-04-22 16:29   ` Brassow Jonathan
2013-04-23  0:05     ` NeilBrown [this message]
2013-04-24  3:48       ` Brassow Jonathan
2013-04-24  6:24         ` NeilBrown

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=20130423100515.5c4c3ee6@notabene.brown \
    --to=neilb@suse.de \
    --cc=jbrassow@redhat.com \
    --cc=linux-raid@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox