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>
NeilBrown
Adam Kwolek
Krzysztof Wojcik
Marcin Labun
Dan Williams
Doug Ledford