When restarting an array that is in the middle of a reshape,
sync_min cannot be set. So just ignore any errors we get
when trying to set it.
Signed-off-by: NeilBrown <neilb@suse.de>
Particular problem was that we didn't unfreeze if a reshape
wasn't needed.
But all that 'rv' stuff isn't needed and some of it was wrong,
so simplify it all.
Signed-off-by: NeilBrown <neilb@suse.de>
We only 'goto release' on error, but that branch contained handling
for non-error conditions: reloading metadata. Obviously that doesn't
work.
So re-arrange the code to make it more of a straight line that is
easier to follow and reload the metadata if that might be at all
needed.
Signed-off-by: NeilBrown <neilb@suse.de>
Everything other than the 'child' part of the 'switch(fork)' returns
quickly, so leave them inside the switch but move the other large bit
out so as to make the flow of code more natural.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ don't pass 'frozen' as an arg to unfreeze - just use it
to conditionally call 'unfreeze'.
2/ Always unfreeze at end of reshape_container
3/ Only unfreeze at end of reshape_array if not 'forked'. So when
reshape_array is called from reshape_container it doesn't unfreeze,
but when called directly.
Signed-off-by: NeilBrown <neilb@suse.de>
When container is passed to grow_reshape(), load_container() function
has to be used to get all required information from metadata.
So load_super is never correct here - in particular, cfd is a
'container fd' so we must 'load_container' on it.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
reshape_super() called from reshape_container() with size set to
info->component_size gives size in reshape_super == -2 due to unsigned
signed conversion (info->component_size is not initializes).
As size is not changed during container reshape '-1' value is passed
to indicate this.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
reshape_array uses text_version to reload the container content,
so make sure it is available.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Add disks fails due to empty sys name field.
sysfs_init fills out required fields for add disk operation.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
To reshape a RAID0 we convert to RAID4 first. This makes it look
like it could be degraded and so we are tempted to ensure there are
enough spares. However this is not appropriate for RAID0, so
explicitly exclude new_level == RAID0 in this check
Reported-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Child_monitor was design to perform 'manage_reshape' for native
arrays. So change the signature for ->manage_reshape to match
child_monitor and move the all to the same place that child_monitor
is called from.
Also give super-intel a manage_reshape handler which simple calls
child_monitor.
Signed-off-by: NeilBrown <neilb@suse.de>
child_monitor has overall responsibility for backups using the generic
bsb, so move all handling under it's control.
signed-off-by: NeilBrown <neilb@suse.de>
We currently suspend rather large sections of
the array which can take a while to process.
Possibly smaller sections are better. Possibly it should be
adjusted on a timeout basis.
Signed-off-by: NeilBrown <neilb@suse.de>
The array might not be a multiple of the chosen backup size, so
the last bit to be backed up might be a bit smaller. Handle that
correctly.
Signed-off-by: NeilBrown <neilb@suse.de>
At some points we need to perform 2 backups at once so as to
start the 'double buffering' approach. So rather than assuming
what the next backup should be, example suspend_point and backup
as much as possible up to there.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ We need to clean up the backup file after the reshape finishes.
2/ We need to remove the suspended region and clear the resync
controls after the resync finishes.
Signed-off-by: NeilBrown <neilb@suse.de>
The array_size we need to consider is the largest possible size of the
array, which is a different calculation depending on whether the array
is growing or shrinking.
Signed-off-by: NeilBrown <neilb@suse.de>
'sync_completed' can sometimes have a value which is slightly high.
So round-down relevant values to new-chunk size and that is what we
want.
Subtract from component_size after scaling down rather than before as
that is easier.
Make sure max_progress never goes negative when reshaping backwards.
Signed-off-by: NeilBrown <neilb@suse.de>
The current code is right.
Instead compute where we might eventually need to back up to, and
then compare that to how far we have progressed.
Also move suspend_point up towards where we might need to backup to,
rather than just as far as max_progress - as max_progress can never
exceed where we are currently suspended to.
Signed-off-by: NeilBrown <neilb@suse.de>
It isn't needed as we always work in multiples of full
destination stripes.
Also multiply by 'after' disks, not before.
We can progress until the point we would write then lines up with
where we would read now.
We read now from
array-address: reshape_progress device-address: read_offset
So we write then to
device-address: read_offset array-address: read_offset * after.disks
Signed-off-by: NeilBrown <neilb@suse.de>
The 'blocks' number computed by analyse_change is the number of
blocks that it makes sense to back-up at a time.
It is the smallest number of blocks that is a whole number of
stripes in both the old and the new layout.
However we are also using it as the smallest amount of progress
that can be made at a time, which is wrong as it is always valid
to progress a single stripe in the new layout.
So change 'blocks' to be called 'backup_blocks' to make it more clear.
And pass new_chunk size down so it can be used for 'minimum forward
progress' calculations.
Also set 'stripes' (the amount actually backed up) from the
possibly-scaled 'blocks' number rather than ignoring it and using
backup_blocks.
Finally, get rid of 'read_range' as it isn't used (or needed).
Signed-off-by: NeilBrown <neilb@suse.de>
Once we have called reshape_container or reshape_super we have handed
on the responsibility for unfreezing the array, so Grow_reshape
shouldn't call unfreeze.
Signed-off-by: NeilBrown <neilb@suse.de>
When converting to RAID6, the new layout should match the old
layout, not the RAID6 version of the old layout.
Signed-off-by: NeilBrown <neilb@suse.de>
We want start_reshape to work no matter what the current values
of suspend_lo/suspend_hi are. So initialise suspend_lo very high
as this allows suspend_hi to be set to anything.
Signed-off-by: NeilBrown <neilb@suse.de>
After raid0 reshape is finished backward takeover has to be executed.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When new disks are added array size has to be set by mdadm as array grows.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For external metadata parameters has to be changed via sysfs.
i.e. change of raid_disks requires handshake mdmon<->md (md_allow_write())
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Metadata is not modified by metadata preparation handler.
It has to be read again from array.
There is 2 read required:
1. before 'for' entry to get updated information after reshape_super() call
2. inside 'for' loop to get updated information for every processed array
(it can happen /i.e. imsm case/ that container operation is a set of array operations
and information in metadata is changed after every loop).
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Combine all the non-backing-up code into a single function:
progress_reshape. It is called repeatedly to monitor a
reshape and allow it to happen safely.
Have a single separate function 'child_monitor' which
performs backups of data and calls progress_reshape to
wait for the next backup to be needed.
Signed-off-by: NeilBrown <neilb@suse.de>
Significant rewrite/refactor of Grow_reshape to make it easier to work
with externally-managed-metadata.
This patch it too big, but we'll just have to live with that.
Signed-off-by: NeilBrown <neilb@suse.de>
With externally managed container based metadata, the ->reshape_super
method must choose any spares that are to be added to the array.
They should be prepared so that ->container_content will find them
as spares (disk.state == 0) which are assigned to a slot
(raid_disk >= 0).
We need to take those and add them to the array(s).
Signed-off-by: NeilBrown <neilb@suse.de>
This means that ->manage_reshape will be called with reshape ready to
roll.
Also move the current start_reshape call earlier so that it is before
the other ->manage_reshape call.
Signed-off-by: NeilBrown <neilb@suse.de>
Rather than sprinkling various sysfs setting around, put them all
in one place. This will make implementing ->manage_reshape easier.
This changes behaviour slightly.
Previously we would not set 'sync_action' to 'reshape' until we were
ready for the process to start. Now we set sync_max to zero and set
sync_action to 'reshape' at that time. When we want reshape to
actually start we advance sync_max.
Signed-off-by: NeilBrown <neilb@suse.de>
The two places that this was done were different. The original was
most correct, thought it used odisks rather than odata.
So fix that and make them both use the same calculation.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ When we sunc_metadata, we must reset ->update_tail else
future metadata updates might go direct to the device bypassing
mdmon.
2/ When converting to an array with redundancy so we can add disks
it is neater to sync_metadata before starting mdmon rather that
artificially setting update_tail early.
Signed-off-by: NeilBrown <neilb@suse.de>
Before we freeze a container in preparation for growing a subarray, we
need to be sure all the subarrays are idle.
This test is racy as recovery could start at any moment following a
failure. However it is still useful as it stops us from even trying
to start a reshape while a reshape or recovery is active.
Signed-off-by: NeilBrown <neilb@suse.de>
Growing an array when there aren't enough spares can make the array
degraded. This works but might not be what is wanted.
So warn the user in this case and require a --force to go ahead
with the reshape.
Signed-off-by: NeilBrown <neilb@suse.de>
Sometimes wait_backup() omits transition from reshape to idle state
and mdadm seams to be hung. So check the 'complete' count
*before* waiting rather than only after.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When wait_reshape() function starts it can occurs that reshape is
finished already, before wait_reshape() start. This can lead to wait
for change state inside this function for a long time. To avoid this
before wait we should test if finish conditions are not reached
already.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown
Krzysztof Wojcik
Adam Kwolek
Marcin Labun