linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: "Dorau, Lukasz" <lukasz.dorau@intel.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
	"Ciechanowski, Ed" <ed.ciechanowski@intel.com>,
	"Patelczyk, Maciej" <maciej.patelczyk@intel.com>
Subject: Re: [PATCH] fix: imsm: mdmon should reread component_size on wakeup
Date: Wed, 26 Sep 2012 10:59:12 +1000	[thread overview]
Message-ID: <20120926105912.268605b7@notabene.brown> (raw)
In-Reply-To: <D9FFE20C522965449E182ACE73889AEB1900CD88@IRSMSX102.ger.corp.intel.com>

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

On Tue, 25 Sep 2012 09:08:45 +0000 "Dorau, Lukasz" <lukasz.dorau@intel.com>
wrote:

> On Thursday, September 20, 2012 3:31 AM NeilBrown <neilb@suse.de> wrote:
> > On Mon, 17 Sep 2012 10:37:55 +0200 Lukasz Dorau
> > <lukasz.dorau@intel.com> wrote:
> > 
> > > Mdmon has not read component_size (in read_and_act()) on wakeup so
> > far.
> > > In case of size's expansion component_size has been changed but
> > > mdmon has not updated it. As a result the metadata was incorrect
> > > during the size's expansion. It has contained no information
> > > that resync was in progress (there has been no checkpoint too).
> > > The metadata has been as if resync has already been finished
> > > but it has not.
> > >
> > > Updating of component_size has been added to read_and_act().
> > > Now mdmon uses the correct value of component_size and the correct
> > > metadata (containing information about resync and checkpoint) is written.
> > 
> > Thanks, but I don't think I like this approach.
> > 
> > In my mind, the 'monitor' thread should only be monitoring things that it has
> > to respond to quickly - before another write can complete.
> > A size change does not need to be so immediate.
> > So I would rather that mdadm updates component_size but not array_size,
> > and
> > then 'ping's the manager.   The manager thread then checks and notices that
> > the component size has changed, asks the monitor to update the metadata,
> > then
> > sets the array_size to match.
> > 
> > Possibly mdadm shouldn't just 'ping' the monitor, but should send the
> > metadata update ... not sure which is best.
> > 
> > Does that make sense to you?
> > 
> 
> Maybe the description of the patch was a bit misleading and I suppose 
> that you have misunderstood me.
> mdadm changes (updates) "component_size", not mdmon. The only thing
> this patch adds is that mdmon rereads the value of "component_size" on wakeup
> in case it has been changed by mdadm in meantime. So far mdmon has read
> "component_size" only once on startup. It was wrong, because if "component_size" 
> has been changed by mdadm (in case of size's expansion), mdmon was using wrong, 
> old value of "component_size". This patch corrects that.
> Is it OK for you?

That is exactly what I understood you to mean.  But I don't agree with it.

It isn't the job of the monitor thread to notice geometry changes.  That is
the job of the manager thread, possibly being told by mdadm via the socket.
The manager should explicitly tell the the monitor to perform a metadata
update when the size changes.
The monitor doesn't monitor chunksize or level or any other part of th
geometry of the array, and it shouldn't monitor component_size either.

NeilBrown


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

  reply	other threads:[~2012-09-26  0:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-17  8:37 [PATCH] fix: imsm: mdmon should reread component_size on wakeup Lukasz Dorau
2012-09-20  1:30 ` NeilBrown
2012-09-25  9:08   ` Dorau, Lukasz
2012-09-26  0:59     ` NeilBrown [this message]
2012-09-26 12:22       ` Dorau, Lukasz
  -- strict thread matches above, loose matches on Subject: below --
2012-09-25  9:18 Lukasz Dorau

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=20120926105912.268605b7@notabene.brown \
    --to=neilb@suse.de \
    --cc=ed.ciechanowski@intel.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=lukasz.dorau@intel.com \
    --cc=maciej.patelczyk@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 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).