From: NeilBrown <neilb@suse.de>
To: "Kwolek, Adam" <adam.kwolek@intel.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"Ciechanowski, Ed" <ed.ciechanowski@intel.com>,
"Neubauer, Wojciech" <Wojciech.Neubauer@intel.com>
Subject: Re: [PATCH 6/9] imsm: FIX: container content gathering is not needed for size set
Date: Thu, 13 Jan 2011 14:04:38 +1100 [thread overview]
Message-ID: <20110113140438.6f62ef2b@notabene.brown> (raw)
In-Reply-To: <905EDD02F158D948B186911EB64DB3D176E1AD80@irsmsx503.ger.corp.intel.com>
On Wed, 12 Jan 2011 15:30:50 +0000 "Kwolek, Adam" <adam.kwolek@intel.com>
wrote:
>
>
> > -----Original Message-----
> > From: NeilBrown [mailto:neilb@suse.de]
> > Sent: Wednesday, January 12, 2011 6:53 AM
> > To: Kwolek, Adam
> > Cc: linux-raid@vger.kernel.org; Williams, Dan J; Ciechanowski, Ed;
> > Neubauer, Wojciech
> > Subject: Re: [PATCH 6/9] imsm: FIX: container content gathering is not
> > needed for size set
> >
> > On Tue, 11 Jan 2011 15:04:35 +0100 Adam Kwolek <adam.kwolek@intel.com>
> > wrote:
> >
> > > Size information is loaded already and there is no need to load it
> > again,
> > > when metadata is not reloaded.
> >
> > Why do you say that? It seems wrong.
> >
> > When growing an array, the size will not change until the reshape
> > completes.
> > When it does complete, it will be mdmon which updates the metadata and
> > records in it the desired size of the array.
> >
> > The only way mdadm can find this number out is by loading the metadata.
> >
> > Where am I wrong?
> >
> > NeilBrown
>
> Size is set in metadata, before reshape start in reshape_super() and remains unchanged during whole reshape.
> After reshape this value doesn't change in metadata also.
> It is possible that this behavior is imsm specific, and for general case reload is required as you describes.
>
If reshape_super does to that (and it looks like it does) then I strongly
suspect that it is wrong.
While an array is in the middle of a migration from one configuration to
another its effective size must be the smaller of those two sizes.
So when we add a device to a RAID5, the device size must stay unchanged until
the migration completes. At the moment when the migration completes the size
can change, not before. So I suspect that the size recorded in the metadata
should be the smaller size.
So I think that apply_reshape_container_disks_update and
imsm_progress_container_reshape need to be fixed to change the size after the migration.
NeilBrown
next prev parent reply other threads:[~2011-01-13 3:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-11 14:03 [PATCH 0/9] OLCE for external meta (cont.) Adam Kwolek
2011-01-11 14:03 ` [PATCH 1/9] imsm: FIX: set correct slot information in metadata (raid0) Adam Kwolek
2011-01-11 14:04 ` [PATCH 2/9] FIX: Cannot add spare to monitored container Adam Kwolek
2011-01-12 5:43 ` NeilBrown
2011-01-12 15:57 ` Kwolek, Adam
2011-01-13 3:07 ` NeilBrown
2011-01-13 15:15 ` Czarnowska, Anna
2011-01-11 14:04 ` [PATCH 3/9] imsm:FIX: one spare can be added to raid0 only Adam Kwolek
2011-01-12 5:44 ` NeilBrown
2011-01-12 15:15 ` Kwolek, Adam
2011-01-11 14:04 ` [PATCH 4/9] imsm: FIX: only one spare is passed in update Adam Kwolek
2011-01-12 5:46 ` NeilBrown
2011-01-11 14:04 ` [PATCH 5/9] imsm: Update metadata for second array Adam Kwolek
2011-01-12 5:48 ` NeilBrown
2011-01-11 14:04 ` [PATCH 6/9] imsm: FIX: container content gathering is not needed for size set Adam Kwolek
2011-01-12 5:52 ` NeilBrown
2011-01-12 15:30 ` Kwolek, Adam
2011-01-13 3:04 ` NeilBrown [this message]
2011-01-11 14:04 ` [PATCH 7/9] imsm: FIX: monitor should initialize 2nd reshape only Adam Kwolek
2011-01-12 5:57 ` NeilBrown
2011-01-11 14:04 ` [PATCH 8/9] FIX: container has to be frozen during reshape Adam Kwolek
2011-01-11 14:04 ` [PATCH 9/9] imsm: Proceed with second array reshape only for frozen container Adam Kwolek
2011-01-11 15:23 ` [PATCH 0/4] RAID 0 to/from RAID5 migration Labun, Marcin
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=20110113140438.6f62ef2b@notabene.brown \
--to=neilb@suse.de \
--cc=Wojciech.Neubauer@intel.com \
--cc=adam.kwolek@intel.com \
--cc=dan.j.williams@intel.com \
--cc=ed.ciechanowski@intel.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 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.