On Wed, 12 Jan 2011 15:30:50 +0000 "Kwolek, Adam" <adam.kwolek@xxxxxxxxx> wrote: > > > > -----Original Message----- > > From: NeilBrown [mailto:neilb@xxxxxxx] > > Sent: Wednesday, January 12, 2011 6:53 AM > > To: Kwolek, Adam > > Cc: linux-raid@xxxxxxxxxxxxxxx; 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@xxxxxxxxx> > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
