Check if reshape restart position is the same as set in md.
If position doesn't match this means that we cannot restart reshape.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
To allow for reshape continuation '--continue' option is added
to grow command.
Function that will be executed in grow-continue case doesn't require
information about reshape geometry. All required information are read
from metadata.
For external metadata reshape can be run for monitored array/container
only. In case when array/container is not monitored run mdmon for it.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
During initrd phase continuing reshape will cause file system context
lost. This blocks ability to control reshape using checkpoints.
To avoid this, during initrd phase assemble has to be executed with
'--freeze-reshape' option. This causes that mdadm restores reshape
critical section only.
Reshape can be continued later after system full boot.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
1. Three missing map_unlock() calls were added.
2. Map file must be unlocked on fork, else child will hold lock.
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Reshape backup should be able to be restored during reshape continuation
also. To reuse already existing code it is moved to function.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
A kernel bug makes handling for arrays using more than 2TB per device
incorrect, and the kernel doesn't stop an array from growing beyond
any limit.
This is fixed in 3.1
So prior to 3.1, make sure not to ask for an array to grow bigger than
2TB per device.
Signed-off-by: NeilBrown <neilb@suse.de>
0.90 arrays can only use up to 4TB per device. So when a larger
device is added, complain a bit. Still allow it if --force is given
as there could be a valid use.
Signed-off-by: NeilBrown <neilb@suse.de>
As the conditional checks, reshape to fewer devices is supported
since Linux kernel 2.6.30 not 2.6.32.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When external metatdata handler supports manage_reshape()
and recover_backup() functions in super switch backup file is not required
and can be omitted. For backup purposes metadata specific mechanisms
are used.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When raid0 is takeovered to degraded raid4, metadata updates has to be
applied via mdmon (raid4 has to be monitored).
It is not possible due to no update_tail pointer initialization
in supertype structure.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Just in case array.level is ever something that we don't expect, make
sure we report an error clearly rather than get confused.
Signed-off-by: NeilBrown <neilb@suse.de>
For external metadata backup location and saving methods depends
on metadata specific implementation details. Currently restore_stripes()
function is able to restore data only from the given backup file handles
and it is used only for assembling partially reshaped arrays.
As this function will be very helpful for external metadata backup
mechanism, add the support for restoring data from the given source buffer.
Add possibility for save_stripes() to work without designation targets.
Save_stripes() can now prepare data for restore_stripes() only.
Signed-off-by: Maciej Trela <maciej.trela@intel.com>
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When an array is resized to have larger members, --assume-clean will
disable any resync if the kernel supports it (2.6.40 and later).
Signed-off-by: NeilBrown <neilb@suse.de>
In an array is auto-readonly then a reshape will not start.
But auto-readonly is only wanted until something is explicitly
done to acknowledge that the array is really wanted.
So it is perfectly correct to switch an auto-readonly array to
'clean' if a reshape has been requested.
Signed-off-by: NeilBrown <neilb@suse.de>
If a device fails while the grow is being monitored but the array is
still functional, the Grow will appear to abort and then almost
instantly restart from where it was up to.
So if it appears to abort, wait up to 10 seconds for a restart (it
should be much much less than this.
Signed-off-by: NeilBrown <neilb@suse.de>
The big 'grow' refactor lost us the ability to configure 'faulty'
arrays through --grow.
So put that back as a special case.
Signed-off-by: NeilBrown <neilb@suse.de>
Analyse_change can give unhelpful error messages if nothing was
changed. This is particularly awkward when only changing --size.
So check and re-introduce a message that was list in commit
5da9ab9874
Signed-off-by: NeilBrown <neilb@suse.de>
If you change the size of a member of an array (e.g. it might be a
dm device that can be resized, or on a smart storage device), md
doesn't notice and so the space cannot be used without explicitly
telling md that the device is bigger.
This change causes "mdadm --grow --size=...." to make sure each
component device is making at least that much space available if it
can.
Normally usage of "--size=max" will cause all devices to make max
space available, the md will use as much as it can of that.
Signed-off-by: NeilBrown <neilb@suse.de>
During reshape restart info->array.raid_disks contains new raid_disks number
It cannot be compared against old disks number. Such check will always fail.
Check raid disks array field against final disks number for restart.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When restarting a reshape, the value of 'raid_disks' is the *new*
value. The old value is found by subtracting delta_disks.
So before calling analyse_change we must set raid_disks to be the
old value, and then reset it afterwards.
All other fields are cleanly separated with the main field being
the 'old' value and a new_* field available.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Values greater than 0, means error. We exit from loop on error
with empty super-block pointer when sd pointer is valid.
This cannot be detected by check condition as error.
For sure we shouldn't go forward with error condition.
It leads to throwing exception with core file when metadata handler
wants to access non existing super-block.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When raid0 expansion is restarted, mdadm refuses to correctly assemble
array because critical section cannot be restored from backup file.
mdadm exits with information:
mdadm: Failed to restore critical section for reshape - sorry.
For raid0 new level is 0, current array level is 4.
Function Grow_restart() doesn't allow for level change.
Grow_restart really shouldn't be checking for level changes.
As they are always instantaneous they should never appear
in the metadata so it doesn't mean anything to check for them.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When we add spared that have been targeted at a specific slot,
we need raid_disks to be bigger than the slot number.
But currently we don't increase raid_disks until after we add
these spares.
So introduce an early increase of raid_disks to allow the spares
to be added.
Signed-off-by: NeilBrown <neilb@suse.de>
When for ping_monitor() input devnum2devname() is used,
received string pointer should be passed to free() for memory release.
It is not made in several places. This use case should have function
to avoid memory leak.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Unfreeze array on success only.
rv is initialized by restart variable so we have 2 cases.
1. regular reshape start
rv == restart == 0
this means that real error (returned by reshape) can cause leaving container frozen
If array is not touched by reshape it can be unfrozen
2. During reshape restart even untouched array under reshape is left unfrozen,
If reshape is started do not unfreeze array on error also.
This allows user for array repair action
(mdmon will not change array state).
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When an array using native metadata is increasing in size, we don't
need to keep monitoring it after the initial 'critical section'.
So detect that case.
If a final level-change is still needed mdadm will wait for that,
otherwise it will simply exit.
Signed-off-by: NeilBrown <neilb@suse.de>
We now test ->reshape_active, but don't set it in a common case.
So just zero out the whole structure to be on the safe side.
Signed-off-by: NeilBrown <neilb@suse.de>
This is done via conversion to RAID4 and back.
To grow the array, extra devices will be needed which cannot
already be present as spares - so allow a list of new devices
to be included in grow request which changed the number of devices.
Signed-off-by: NeilBrown <neilb@suse.de>
When an RAID0 is started using SET_ARRAY_INFO ioctl the
component_size will be zero.
This confused the code for reshaping a RAID0 via RAID4.
So if that seems to be the case, fake a believable component_size
Signed-off-by: NeilBrown <neilb@suse.de>
For not reshaped array in container during assembly array is in
auto-read-only state. It is not possible to set disk slot for such
array and later reshape cannot be started also. To move array from
'auto-read-only' to 'active' state storing 'active' state to sysfs is
added. This allows for disks configuration and reshape.
During reshaped array restart it is disabled by condition on restart
variable.
When reshape is starting, storing 'active' state to already active
array should not matter.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
when starting an array that is in the middle of a migration,
we need to start mdmon, just as we do for arrays which are not
in the middle of a migration.
Repored-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
st->sb is null. This is exception cause.
reshape_container() function expects that super block will be loaded.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This is a bit of a hack - probably analyse change needs to be
re-written a bit to handle this properly.
However when the metadata deduced the intermediate state for a
reshaping array, the 'new_level' it sets should not be used to
interpret the 'delta_disks' number.
So in that case, hide the new_level while calling analyse_change.
Signed-off-by: NeilBrown <neilb@suse.de>
The 'raid_disks' for a container is zero, so subtracting it
from the given raid_disks to get delta_disks doesn't make sense.
Rather set delta_disks to UnSet and set raid_disks to the requested
number of disks. This then gets passed to reshape_super() which
can use it as required.
Signed-off-by: NeilBrown <neilb@suse.de>
The check that the array info is already in 'native format' is
only relevant when restarting a growth, so only perform it then.
Signed-off-by: NeilBrown <neilb@suse.de>
Normally when reshape_array is called with restart == 0,
info->array is the same as the 'array' read from the kernel
(via ioctl) so both have the same level.
However when called from reshape_container, info->array was
generated by the metadata so it will have 'level' set to the
intermediate (or final) level already.
So to test if we need to change the level, we need to compare the
desired level with that which was loaded from the kernel (array.level)
rather than that which was read from metadata (info->array.level).
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The check for 'enough spares' doesn't apply to RAID0 as we don't
mind it going degraded. But add a test that there are enough spares
to actually produce a working array.
Signed-off-by: NeilBrown <neilb@suse.de>
Some grow operations must be applied to a whole container. These
are performed one array at a time, so only one array appears to
be reshaping.
When re-assembling such an array, we need to make sure that
when the reshape finished, we move on to the next array.
So require metadata to set ->reshape_active = 2 in that case,
and use reshape_container to complete the reshape.
Signed-off-by: NeilBrown <neilb@suse.de>
Now that the external metadata handler must provide an md-compatible
old/new geometry, sys_set_array can do all of the array set-up for
an array that is undergoing reshape.
That leave less for reshape_array to do.
Also clean up how reshape_array tells if the reshape has started or
not.
Don't use ->reshape_active as that doesn't tell us anything consistent
at this stage, only use the 'restart' flag passed in.
Signed-off-by: NeilBrown <neilb@suse.de>
When assembling array using assemble_container_content() for external
metadata case, array is in 'readonly' state already.
There is not necessary to duplicate this operation.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When calling reshape_array() for external metadata 'container name'
parameter have to be passed.
Find and pass container name in external metadata case.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Adam Kwolek
Lukasz Dorau
NeilBrown
Namhyung Kim
Luca Berra