check_reshape should not try to parse the subarray string - only
metadata handlers are allowed to do that.
The common code and only interpret a subarray string by passing it to
"container_content" which will then return only the member for that
subarray.
So remove check_reshape and place similar logic explicitly at the two
call-sites. They are different enough that it is probably clearer to
have explicit code.
Signed-off-by: NeilBrown <neilb@suse.de>
container_content retrieves volume information from disks in the
container. For unsupported volumes the function was not returning
mdinfo. When all volumes were unsupported the function was returning
NULL pointer to block actions on the volumes. Therefore, such volumes
were not activated in Incremental and Assembly. As side effect they
also could not be deleted using kill-subarray since "kill" function
requires to obtain a valid mdinfo from container_content.
This patch fixes the kill-subarray problem by allowing to obtain
mdinfo of all volumes types including unsupported and introducing new
array.status flags.
There are following changes:
1. Added MD_SB_BLOCK_VOLUME for blocking an array, other arrays in the
container can be activated.
2. Added MD_SB_BLOCK_CONTAINER_RESHAPE block container wide reshapes
(like changing disk numbers in arrays).
3. IMSM container_content handler is to load mdinfo for all volumes
and set both blocking flags in array.state field in mdinfo of
unsupported volumes. In case of some errors, all volumes can be
affected. Only blocked array is not activated (also reshaped as
result). The container wide reshapes are also blocked since by
metadata definition they require modifications of both arrays.
4. Incremental_container and Assemble functions check array.state and
do not activate volumes with blocking bits set.
5. assemble_container_content is changed to check container wide reshapes
before activating reshapes of assembled containers.
6. Grow_reshape and Grow_continue_command checks blocking bits
before starting reshapes or continueing (-G --continue) reshapes.
7. kill-subarray ignores array.state info and can remove requested array.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When array reshape (e.g. raid0->raid5 migration) is restarted during
array assembly, file system placed on this array cannot be mounted until
reshape is finished due to "busy" error.
This is caused when reshape is executed on array for external metadata
and array handle is cloned /forked/ to child process environment but not
closed.
Handle can't be closed before executing Grow_continue() because it is
used later in code.
Close unused handle in child process /reshape_container()/.
It is similar to close fd handle in reshape_array() before calling
manage_reshape()/child_monitor() in Grow.c:2290.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Pinging the monitor for a NULL container is bad.
Reported-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Tested-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Signed-off-by: NeilBrown <neilb@suse.de>
So far there were 2 reshape continuation cases:
1. array is started /e.g. reshape was already invoked during initrd
start-up stage using "--freeze-reshape" option/
2. array is not started yet /"normal" assembling array under reshape case/
This patch narrows continuation cases in to single one. To do this
array should be started /set readonly in to array_state/ before calling
Grow_continue() function.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This patch version is simplified compared to previous one.
There is no use of freeze_reshape flag in start_reshape(). It is assumed
that for reshape starting condition reshape_progress field contains
0 value /correct start position/. For reshape restart case, it contains
correct restart position. This approach doesn't make start_reshape()
difficult to read/manage and /imho/ kernel changes to change mdstat
reporting behavior are not necessary.
Setting correct position allows user to see it in the mdstat during
reshape restart and reshape process is not reported as resync.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Grow_continue() for external metadata should be executed on blocked
from monitoring array(s)/container.
Additional call to freeze() is not necessary in such case.
It produces meaningless error message only.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
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>
When changing level when a new number of raid disks was explicitly
specified, we much make sure that the change implied by the
change in level is properly incorporated into the final result.
So explicitly track the change in number of parity disks
(delta_parity) and use it together with delta_disks to determine
final data_disks.
Also set info->delta_disks so other code doesn't need to mirror
this analysis.
And add some errors in cases where a new number of disks was
requested but is not currently supported
Reported-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Transition raid5 to raid0 was not covered in analyse_change()
Missing case added.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For external metadata cases, information about number of spares cannot
be get via ioctl GET_ARRAY_INFO for particular array
(as info variable is initialized by). In md this information is present
in container object not array one.
This causes need to get spare disks number from external metadata.
This information is required for reshape_array() function to decide
if spare disks number satisfy operation requirements.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Delta_disk can be set to UnSet value.
This can a cause to pass wrong parameter to reshape_super().
To avoid such situations raid_disks and delta_disks parameters
have to be passed to reshape_super() separately.
It will be up to reshape_super() function validation
and usage of this parameters to avoid not valid values.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
After level migration array is left frozen.
When process is not externally forked reshape_array() should
unfreeze array before exit (this is not container operation).
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Problem occurs when we want to expand single disk raid0 array.
This is done via degraded 2 disks raid4 array. When new spare disk
for reshape is added to array, md immediately initiates recovery before
mdadm can configure and start reshape. This is due fact that 2 disk
raid4/5 array is special md case.
Mdmon does nothing here because container is blocked.
This is caused because after takeover array is not in frozen state in md.
Put array in to frozen state after takeover to allow mdadm to finish
configuration before reshape is executed in md.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When container operation fails before child process starts,
array can be left frozen because container_reshape() doesn't make
unfreeze() operation in all error cases, as it is responsible for.
add unfreeze() operation for error case scenarios in reshape_container()
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
reshape_prepare_fdlist and child_monitor currently have slightly
different ideas of the 'old number of raid devices' which can cause
major confusion.
So settle on one value, and assign it to odisks early and always use
it.
Signed-off-by: NeilBrown <neilb@suse.de>
kernel requires sync_max to be a multiple of the current
chunk size. This is not really 'correct', but we need to work
with it. So round down.
Signed-off-by: NeilBrown <neilb@suse.de>
Due to a miscalculation we didn't initialise the whole file.
There is 4K (8 sectors) for the metadata, then the data.
Signed-off-by: NeilBrown <neilb@suse.de>
When restarting a reshape with internal metadata, the new geometry
is already set and the reshape has been start (but has not been
allowed to continue yet).
So in that case, don't set things and don't ask for a reshape.
Signed-off-by: NeilBrown <neilb@suse.de>
The value of 'array' might not be current, so SET_ARRAY_INFO
and fail. Just refresh it before setting raid_disks.
Signed-off-by: NeilBrown <neilb@suse.de>
Problem has been observed when raid10<->raid0 takeover operation
is executed.
In code updating layout, raid_disks and chunk_size for non-restriping
operations in reshape array functions SET_ARRAY_INFO ioctl call was
not succeeded.
Takeover process finish execution with error, mdadm shows message:
"mdadm: failed to set disks"
Cause is not meeting SET_ARRAY_INFO ioctl requirements:
- only one parameter may be changed at one time
- level of current array info and new info should be the same
Patch introduces solution for this issue.
At the beginning of discussed code we read current information
about array and then compare them with new values should be set.
If particular value is different (and should be set),
we are overwrite only this one in array info and then call ioctl.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For raid10 -> raid0 takeover operation we should reject disks
in mirror by marking them as 'failed' and then remove them from
array by writing "remove" to disk state.
For external metadata second action is executed by mdmon.
According the description in monitor.c:175 when monitor detect
"faulty" in device state, it blocks the device, mark it as failed
in metadata, unblocks the device and finally writes "remove"
to device state.
For external case writing "remove" to device state in mdadm
is not necessary and harmful.
It may cause following issues:
1. "remove" operation for external case in mdadm is not finish
with successful result because monitor may block the device or disk
has been already removed by monitor.
2. If disk is removed by mdadm earlier than mdmon catch "failed" state,
metadata is not properly updated- is not marked as failed.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
After loop can occurs that due to 0 value reported by kernel
we have 0 in completed variable.
This is wrong. we are interested in real completed point.
0 value means that we reached sync point set in md,
so we can set completed variable to just reached point.
this point value is stored in max_progress variable.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
mdadm should verify if reshape is started before it goes
in to check-pointing machine.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Problem occurs when we want to expand single disk raid0 array.
This is done via degraded 2 disks raid4 array. When new spare
is added to array, md immediately initiates recovery before
mdadm can configure and start reshape. This is due fact that 2 disk
raid4/5 array is special md case. Mdmon does nothing here because
container is blocked.
Put array in to frozen state allows mdadm to finish configuration
before reshape is executed in md.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When analyse_change sets level=1, data_disks is meaningless
as is layout.
So don't set them, and make sure we ignore them.
Signed-off-by: NeilBrown <neilb@suse.de>
Add support for raid1 to raid0 takeover operation in user space.
This patch includes support for native and imsm metadata.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
During reshape when reshape is finished in md, progress_reshape() hangs
on select().
This is because 'sync_completed' is reset to zero before 'sync_action'
becomes 'idle', and we don't look for notification on 'sync_action'.
So if completed becomes zero after reshape_progress has made some
progress, then deduce that reshape has finished.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
when in container are present raid0 and raid5 arrays, and reshape order is:
1. raid0 array
2. raid5 array
mdadm cannot set new raid_disks for raid0 array. For this action md has to have
handshake with mdmon. We have the following conditions:
1. Raid0 is not monitored
2. raid0 has been just takeovered to raid4/5 (it has to be monitored
3. monitor has to start monitor new raid4/5 array
4. monitor is not started (it is started to second raid5 array)
In such situation pig_monitor is required to let know to m monitor about new array
(not in the starting monitor case only)
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The patch introduces takeover from level 10 to level 0 for imsm
metadata. This patch contains procedures connected with preparing
and applying metadata update during 10 -> 0 takeover.
When performing takeover 10->0 mdmon should update the external
metadata (due to disk slot and level changes).
To achieve that mdadm calls reshape_super() and prepare
the "update_takeover" metadata update type.
Prepared update is processed by mdmon in process_update().
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
- when reshaping a container, ->reshape_active is already set
even though it isn't really active yet, so we need to set
the new geometry even when reshape_active is set. This is safe.
- When restarting a reshape, make sure the reshape_position is set
appropriately when external metadata is used.
Signed-off-by: NeilBrown <neilb@suse.de>
Only adjust reshape_progress based on the backup that was found
if the backup covered the current reshape_progress point.
Signed-off-by: NeilBrown <neilb@suse.de>
When reshaping backwards we only backup from backup_blocks to
the start, so initialise backup_point appropriately.
Signed-off-by: NeilBrown <neilb@suse.de>
I'm seen mdadm spinning while failing to read 'degraded'.
This doesn't really fix it, but is a reminder that it needs to be
fixed.
Signed-off-by: NeilBrown <neilb@suse.de>
When reshaping from the end of the array to the start, for times
when the number of data devices is decreasing, the handling of the
backup area isn't a simple mirror of the handling on low-to-hi
reshapes as the backup areas is always low in the array.
So re-write that to make it work.
Signed-off-by: NeilBrown <neilb@suse.de>
When reshaping it is correct to open containers exclusively, but not
arrays. The array could very easily be in use, e.g. by a mounted
filesystem.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For non re-striping transitions array must be unfrozen
before end of processing.
For restriping transitions we normally let the child
unfreeze the array but in this case there is no child.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
reshape.after.data_disks field must be initiated
for raid0<->raid10 transition.
Instead calculated spares_needed variable in reshape_array
function has random value.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When mdadm falls in "reduce size" error on takeovered array it jumps
to release and tries execute backward takeover. This time sra pointer
is not initialized and coredump is generated.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When we restart an array in the middle of a reshape, we reuse a lot of
the code for starting the reshape, but it needs to know that
circumstances are slightly different.
So add a 'restart' arg which is used:
- skip checking and adding spares
- activate the array (rather than start reshape)
- allow the backup file to already exist
Signed-off-by: NeilBrown <neilb@suse.de>
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>
Move opening backup file to the function for future reuse during
container reshape.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Check on upper limit of number of devices was in the wrong place.
Result was could not create array with more than 27 devices without
explicitly setting metadata, even though default metadata allows more.
Fixed, and also perform check when growing an array.
Signed-off-by: NeilBrown <neilb@suse.de>
Though not having the proper backup file can cause data corruption, it
is not enough to justify not being able to start the array at all.
So allow "--invalid-backup" to be specified which says "just continue
even if a backup cannot be restored".
Signed-off-by: NeilBrown <neilb@suse.de>
If adding a bitmap fails with EBUSY, then it is because the array is
currently resyncing/recovering/reshaping.
As this is non-obvious, give a message explaining the fact.
Signed-off-by: NeilBrown <neilb@suse.de>
number of backup blocks evaluation is put in to function for code reuse.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
fd handles table creation is put in to function for code reuse.
In manage_reshape(), child_grow() function from Grow.c will be reused.
To prepare parameters for this function, code from Grow.c can be
reused also.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Until now Raid10->Raid0 takeover was possible only if all the mirrors
where removed before md starts the takeover. Now mdadm, when
performing Raid10->raid0 takeover, will remove all unwanted mirrors
from the array before actual md takeover is called.
Signed-off-by: Maciej Trela <maciej.trela@intel.com>
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When growing the number of raid disks the reshape process will promote
container-spares to subarray-spares (later the kernel promotes them to
subarray-members in raid5_start_reshape()). The automatic spare
promotion that mdmon performs upon seeing a degraded array must be
disabled until the reshape process has been initiated. Otherwise, mdmon
may start a rebuild before the reshape parameters can be specified.
In the external case we arrange for the monitor to be blocked, and
turn off the safemode delay.
Mdmon is updated to check sync_action is not frozen before initiating
recovery.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
In the native metadata case Grow_reshape() and the kernel validate what
reshapes are possible / supported and the kernel handles all the metadata
updates. In the external case the metadata format may have specific
constraints above this baseline. External formats also introduce the
constraint of only permitting some reshapes at container scope versus subarray
scope. For exmaple imsm changes to 'raiddisks' must be applied to all arrays
in the container.
This operation assumes that its 'st' parameter has been obtained from
super_by_fd() (such that st->subarray is up to date), and that a snapshot of
the metadata has been loaded from the container.
Why a new method, versus extending an existing one?
->validate_geometry: this routine assumes it is being called from Create(),
adding reshape complicates the cases that this routine needs to handle. Where
we find that checks can be shared between the two cases those routines
refactored into common code internal to the metadata handler, i.e. no need to
provide a unified external interface. ->validate_geometry() also does not
expect to update the metadata.
->update_super: this is meant to update single fields at Assembly() and only at
the container scope. Reshape potentially wants to update multiple fields at
either container or subarray scope.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If the user does not specify a layout, don't skip asking about retaining
the non-standard raid6 layout which may be implicitly changed.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Going through the Grow api found some local routines that could be
marked static.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Rather than hiding this in the 'st', return it explicitly.
In the one case we still need it, copy it into st where needed.
This will disappear in a future patch.
Signed-off-by: NeilBrown <neilb@suse.de>
To accurately detect when an array has been split and is now being
recombined, we need to track which other devices each thinks is
working.
We should never include a device in an array if it thinks that the
primary device has failed.
This patch just allows get_info_super to return a list of devices
and whether they are thought to be working or not.
Signed-off-by: NeilBrown <neilb@suse.de>
nr_disks is just wrong here - the arrays need room for all disk slots,
even if some are empty, plus spares, plus a possible backup file.
So raid_disks is correct.
Signed-off-by: NeilBrown <neilb@suse.de>
There 'rv' tests were confused and sometimes wrong.
This resulted in not writing the second bsb.
Also fix the test script so the the critical section is long enough
that we have some hope of interrupting it.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ and extra local var was declared, which causes rv setting
to be lost
2/ a -ve rv was left -ve while we should be return 1 on err.
Signed-off-by: NeilBrown <neilb@suse.de>
...i.e. GET_DEVS == (GET_DEVS|SKIP_GONE_DEVS)
A null pointer dereference in Incremental.c can be triggered by
replugging a disk while the old name is in use. When mdadm -I is called
on the new disk we fail the call to sysfs_read(). I audited all the
locations that use GET_DEVS and it appears they can tolerate missing a
drive. So just make SKIP_GONE_DEVS the default behaviour.
Also fix up remaining unchecked usages of the sysfs_read() return value.
Reported-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
A recent change move the sysfs_read call away from the check that it
succeeded. This patch moves the check back next to the sysfs_read
call.
Signed-off-by: NeilBrown <neilb@suse.de>
Chunks aren't particularly big, but when you could them in bytes
and multiply them together (as we do for calculating the backup
size for 'grow') they can overflow a 32bit int.
So group the division by 512 more closely with the
chunk size so were would need 30Meg chunks to come close to
overflowing 32bits.
Signed-off-by: NeilBrown <neilb@suse.de>
When checking if the new chunk size fit in the component size
we were confusing sectors and K, and so getting it wrong.
Signed-off-by: NeilBrown <neilb@suse.de>
When building mdadm.O2, set _FORTIFY_SOURCE to get more
warnings, and also build mdmon.O2 to find warnings in that
code too.
Then fix the warnings.
Suggested-by: Luca Berra <bluca@comedia.it>
Signed-off-by: NeilBrown <neilb@suse.de>
As backup file has a timestamp which is updated quite separately
from the metadata timestamp. They should be largely in-sync but
sometimes are not.
So be more generous in the check, and allow it to be over-ridden
by an environment variable.
Signed-off-by: NeilBrown <neilb@suse.de>
If a bitmap exists on an array, then current kernels cannot grow
that array.
So when we try to grow an array, test for EBUSY and if a bitmap is
present, report that the bitmap needs to be removed.
Resolves-Debian-Bug: 534571
Signed-off-by: NeilBrown <neilb@suse.de>
These were never supposed to be released, and due
to a type issue they cause compile problems on
some architectures.
Resolves-Debian-Bug: 567167
Signed-off-by: NeilBrown <neilb@suse.de>
As array.size is 32bit we need to prefer the 'component_size'
read from sysfs when that is available.
Grow wasn't always suitably careful.
Signed-off-by: NeilBrown <neilb@suse.de>
array.size is only 32bit so it is not safe to multiply it
up before casting to (long long).
Actually, we shouldn't be using array.size here at all, but that
will get fixed in a subsequent patch.
Reported-by: Andrew Burgess <aab@cichlid.com>
Signed-off-by: NeilBrown <neilb@suse.de>
A change the reduces the size of an array always happens
before any other change. So it can cause data to be lost.
By themselves these changes are reversible. But once another
change has started, the data would be permanently lost.
So recommend data integrity be checked between a size change
and any other change.
Signed-off-by: NeilBrown <neilb@suse.de>
2.6.31 has a bug which can lead to unsafe reshaping.
So only allow a reshape with 2.6.32.
When the required fixed get into 2.6.31.y, this can be relaxed
slightly
Signed-off-by: NeilBrown <neilb@suse.de>
We were using ->component_size while it hadn't been set.
This effectively meant that 'blocks' wasn't multiplied by
16 and reshape was even slower than it should have been.
Signed-off-by: NeilBrown <neilb@suse.de>
If an array goes degraded during reshape, we need to
adjust the devices we read from so as not to back up
stale data.
Signed-off-by: NeilBrown <neilb@suse.de>
The 'arraystart' is in sectors while restore_stripes requires
bytes, so we need a conversion.
Without this, backups get restored to the wrong offset.
Reported-by: "KueiHuan Chen" <kueihuan.chen@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Originally the backup-metadata was only written once at the
start of a raid5 reshape that made the array bigger. So we only
set the mtime once.
Now that we can be writing metadata continually during an in-place
reshape, we need to update the mtime more often.
Also, allow the metadata mtime to be slightly in advance of the
array mtime. Normally the difference will be less than a second,
so 10 minutes should be plenty. This guards against an old backup
file being used to restart an array. but starting two reshapes in the
10 minutes is sufficiently unlikely, and the possibility of an
accident is already sufficiently small, that 10 minutes is probably
fine.
Thanks to Guy Martin <gmsoft@tuxicoman.be> for discovering and
reporting that .mtime wasn't being updated properly.
Signed-off-by: NeilBrown <neilb@suse.de>
FIXME this is wrong . what direction does reshape_position move?
If the device count in an array is shrinking, the critical
region is different so the tests need to be different when
restarting.
Signed-off-by: NeilBrown <neilb@suse.de>
On small (test) arrays, multiplying by 16 can make the 'chunk' size
larger than half the array, which is a problem.
Signed-off-by: NeilBrown <neilb@suse.de>
The last time wait_backup is called, it might see reshape
finish and so return an error indicator.
But this is not an error, and we must go ahead and prepare
the array for full access.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ allow --size to be given with 'G' or 'T' suffix.
2/ allow size to exceed 32bits, and in that case write through sysfs.
Signed-off-by: NeilBrown <neilb@suse.de>
This allows the layout to be parsed after the current level of the
array is know, so that the level doesn't need to be given (otherwise
pointlessly) on the command line.
Signed-off-by: NeilBrown <neilb@suse.de>
For short reshapes the kernel may be done before mdadm can check that
progress has passed the critical section.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If an array reshape completed within 1 second, then --grow will not
notice that it has finished and will keep waiting for the critical
section to pass.
So be more cautious in the test.
Signed-off-by: NeilBrown <neilb@suse.de>
Since we introduced O_DIRECT for device access we need
properly aligned buffers and IO requests. The reshape code
missed out on the conversion.
Signed-off-by: NeilBrown <neilb@suse.de>
Fix on call that passed an invalid mode to open
Don't pass a third arg unless we also pass O_CREAT
Use symbolic args for 2nd and 3rd args
Signed-off-by: Doug Ledford <dledford@redhat.com>
Using buffered IO risks non-atomic updates to parts of the
device that we don't actually want to write to. This isn't in
general safe.
So switch to O_DIRECT for all that IO and make sure we have
properly aligned buffers.
The last release broke the ability to assemble an array that
was in the middle of a reshape.
This patch adds code to test if the critical section needs
to be restored or not so that - if we have failed to restore it,
we know whether to fail or not.
Make sure that if --assemble find an array in the critical region
of a reshape, and cannot find the critical data to restart the
reshape, it gives an error message.
The new superblock needs to have a new disk.number. This is a bit of a hack...
Fix handling of negative bitmap offsets on 64bit hosts.
The bitmap offset is a signed 32bit number, so casting to (long)
isn't sufficient. We must cast to (int32_t).
Fix various problems with --grow --add for linear.
The code to add a drive to a live linear array had never
been tested properly and so was buggy. This tidies it up
and means that the new regression-test passes.
Depending on the size of the array we reserve space for up to 128K
of bitmap, and we use it where possible.
When hot-adding to a version 1.0 we can still only use the 3K at the
end though - need a sysfs interface to improve that.
If a small chunksize is requested on Create, we don't auto-enlarge
the reserved space - this still needs to be fixed.
From: Luca Berra <bluca@vodka.it>
glibc 2.4 is pedantic on ignoring return values from fprintf, fwrite and
write, so now we check the rval and actually do something with it.
in the Grow.c case i only print a warning, since i don't think we can do
anything in case we fail invalidating those superblocks (is should never
happen, but then...)
Signed-off-by: Neil Brown <neilb@suse.de>
When creating a file bitmap, choose a default size that
results in fewer than 2^21 chunks. Without this kmalloc
failure in the kernel becomes likely.
Signed-off-by: Neil Brown <neilb@suse.de>
To support resizing an array without a spare, mdadm now understands
--backup-file=
which should point to a file for storing a backup of critical data.
This can be given to --grow which will create the file, or
--assemble which will restore from the file if needed.
Signed-off-by: Neil Brown <neilb@suse.de>
- report Intent Bitmap in --detail
- report internal bitmap in --examine
- pass' --force through to --grow --bitmap
- support v.large arrays in --grow --bitmap
Signed-off-by: Neil Brown <neilb@suse.de>
Support "--build"ing arrays with bitmaps.
hot-removal of bitmaps
--re-add of drives recently removed.
assorted extra tests
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>