linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Mike Snitzer <snitzer@redhat.com>
Cc: jbrassow@redhat.com, agk@redhat.com, dm-devel@redhat.com,
	linux-raid@vger.kernel.org
Subject: Re: [PATCH v3 0/8] dm-raid (raid456) target
Date: Thu, 6 Jan 2011 21:46:45 +1100	[thread overview]
Message-ID: <20110106214645.2bd321f4@notabene.brown> (raw)
In-Reply-To: <20110105223628.GA13164@redhat.com>

On Wed, 5 Jan 2011 17:36:29 -0500 Mike Snitzer <snitzer@redhat.com> wrote:

> On Mon, Dec 20 2010 at 10:14pm -0500,
> Neil Brown <neilb@suse.de> wrote:
> 
> > On Mon, 20 Dec 2010 21:37:37 -0500 Mike Snitzer <snitzer@redhat.com> wrote:
> > 
> > > I reviewed all patches and adjusted patch headers in preparation for
> > > inclusion in Alasdair's tree (upstream target being v2.6.38).  The 2
> > > md/bitmap changes can obviously go through Neil's MD tree if that is
> > > preferred.
> > > 
> > > - added Copyright to the top of dm-raid.c
> > > - fixed drivers/md/Kconfig so that DM_RAID will select MD_RAID456
> > > - removed unused 'conf' variable in raid_status()
> > > - few misc style and whitespace changes
> > > 
> > > Neil,
> > > Hopefully you're comfortable with the authorship of most of these
> > > patches still being attributed to you (despite Jon's changes to your
> > > original patches).
> > > 
> > > Please advise, thanks!
> > 
> > I haven't had a chance to have a proper look yet, and I'm about to go on
> > leave for a couple of weeks.
> > I'm probably happy with the authorship remaining as-is, but I reserve the
> > right to change my mind (about anything) once I've had a chance to have a
> > proper look.
> 
> Hi Neil,
> 
> Please advise on how you'd like things to proceed with this initial 8
> patch set.  Ideally we'd get them in to linux-next now and ultimately
> 2.6.38 before the merge window closes.
> 
> Thanks,
> Mike

Sorry for long delays ... leave is always followed by piles of things that
all need to be done at once :-(

Patches 1 and 2 aren't really needed - I feel inclined not to remove that
stuff until all the dust settles..  So I'll put them at the bottom of my
queue and bring them forward in a couple of releases if that seems
appropriate.

Patch 3 I'll push out through my tree shortly.

The rest I am happy with going out through 'dm' to -next and beyond whenever
you like.

However I will take this opportunity to suggest that the raid parameters
might need a bit of review before they are finalised.

The possible parameters are as follows:
 <chunk_size>		Chunk size in sectors.
 [[no]sync]		Force/Prevent RAID initialization
 [rebuild <idx>]	Rebuild the drive indicated by the index
 [daemon_sleep <ms>]	Time between bitmap daemon work to clear bits
 [min_recovery_rate <kB/sec/disk>]	Throttle RAID initialization
 [max_recovery_rate <kB/sec/disk>]	Throttle RAID initialization
 [max_write_behind <value>]		See '-write-behind=' (man mdadm)
 [stripe_cache <sectors>]		Stripe cache size for higher RAIDs


'rebuild idx' only allows one device to be rebuilt at a time.  With RAID6 it
is possible that two devices can be ready for rebuild, in which case we would
want to rebuild both of them.
Also if you stop an array during a rebuild you really want to start again
where you were up to.

Most general solution would be to combine the rebuild information with the
list of component devices - either a sector number or something to indicate
that the rebuild it complete (which could be just a v.big sector number).

I'd much prefer 'daemon_sleep' to be in seconds, we decimals supported if
needed.

Also:

3:	<#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>

This doesn't allow offsets into the various devices like dm-stripe,
dm-linear, dm-raid1 all do.

So I suspect a bit of work is needed there.

NeilBrown

  reply	other threads:[~2011-01-06 10:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-21  2:37 [PATCH v3 0/8] dm-raid (raid456) target Mike Snitzer
2010-12-21  2:37 ` [PATCH v3 1/8] md/bitmap: revert dm-dirty-log preparation Mike Snitzer
2010-12-21  2:37 ` [PATCH v3 2/8] md/bitmap: use DIV_ROUND_UP in bitmap_init_from_disk Mike Snitzer
2010-12-21  2:37 ` [PATCH v3 3/8] md/raid5: use sysfs_notify_dirent_safe to avoid NULL pointer Mike Snitzer
2010-12-21  2:37 ` [PATCH v3 4/8] dm raid: skeleton raid456 target support Mike Snitzer
2010-12-21  2:37 ` [PATCH v3 5/8] dm: introduce target callbacks and congestion callback Mike Snitzer
2010-12-21  2:37 ` [PATCH v3 6/8] dm: per-target unplug callback support Mike Snitzer
2010-12-21  2:37 ` [PATCH v3 7/8] dm raid: add iterate_devices and io_hints functions Mike Snitzer
2010-12-21  2:37 ` [PATCH v3 8/8] dm raid: add suspend and resume functions Mike Snitzer
2010-12-21  3:14 ` [PATCH v3 0/8] dm-raid (raid456) target Neil Brown
2011-01-05 22:36   ` Mike Snitzer
2011-01-06 10:46     ` NeilBrown [this message]
2011-01-06 14:43       ` Jonathan Brassow
2011-01-10  0:37         ` NeilBrown
2011-01-10 20:14           ` Jonathan Brassow
2011-01-06 15:56       ` [dm-devel] " Phillip Susi
2011-01-06 20:59         ` Jonathan Brassow
2011-01-06 21:01       ` Jonathan Brassow

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=20110106214645.2bd321f4@notabene.brown \
    --to=neilb@suse.de \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=jbrassow@redhat.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=snitzer@redhat.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).