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>
NeilBrown
Krzysztof Wojcik
Adam Kwolek
Marcin Labun