Spares that are specified on container can be used by any array in container.
this means that for every array in container they should be reported.
This let caller know how many spare devices (not used in any array)
are still available.
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>
Because IMSM_ORD_REBUILD is set in second map not first.
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
chunk is in K so size must be converted to K before it is rounded.
Otherwise we may get wrong freesize returned
resulting in creation failure.
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
During metadata printout in '-E' option failed disk map field
information is missing. Add this information to mdadm '-E' option
output.
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>
Use single enum definition/migration type for all migrations.
Using separate definitions causes limitation for number of changes
in metadata implementation during single update for migration/reshape.
Single CH_MIGRATION enum allows for many mtadata parameters change
in single update. It will be possible to change i.e. chunk size together
with raid level. In current implementation 2 metadata updates would be
required for such action, one using CH_CHUNK_MIGR and second using
CH_LEVEL_MIGRATION migration type.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Transition raid0 to raid5 is not possible
due to wrong condition in imsm_analyze_change().
Current condition blocks migration possibility instead allow for it.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Patch introduces test for raid1 to raid0 takeover operation
verification for imsm metadata format.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Parameters in UT suit 13 were wrongly chosen. This causes that
computed number of backup blocks was too big comparing to loop devices
size used in test. Changes in test parameters (chunk, array size)
causes that backup blocks passes mdadm condition for very small
loop devices.
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>
When imsm container is created it have different blocks number
in /proc/mdstat depending on containing array raid level (raid0/raid5).
raid5 case:
md127 : inactive sdd[3](S) sde[2](S) sdc[1](S) sdb[0](S)
2884 blocks super external:imsm
raid0 case:
md127 : inactive sdd[3](S) sde[2](S) sdc[1](S) sdb[0](S)
836 blocks super external:imsm
Due to this, it cannot be compared to one value for both cases.
Test imsm container existence before unit test run only.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
On wrong starting container reshape conditions, mdadm returns information on console:
mdadmimsm: Operation is not allowed on this container
it is changed to:
mdadm: (imsm) Operation is not allowed on this container
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Added tests for cases when:
0 - there is no config file at all
0a - config file has no domains defined
9a - spare is in global domain
15 - spare is in global domain for $platform metadata
Test 4 pass condition changed for imsm metadata.
disk_policy only adds controller domain for imsm
when config_rules_has_path=1.
If there are any domains in config then every disk will have also
a controller domain.
As a result the array needing spares has at least
one controller domain even when it doesn't have any other
domains specified explicitly. In this case any spare in the same
controller domain matches when it has no other domains from config.
(This behaviour is different from the case when there is no paths
in config at all as array domain then is null and no spare matches)
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If initial resync or recovery of a redundant array is not finished
before it is stopped then during assembly md will start it as inactive.
Writing readonly to array_state in assemble_container_content
fails because md thinks the array is during reshape.
In fact we only have a reshape if both current and previous map
states are the same. Otherwise we may have resync or recovery.
Setting reshape_active in such cases causes the issue.
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
> test_stripe assumes that the data starts at the start of each device.
> AS you are using 1.2 metadata (the default), data starts about 1M in to
> the device (I think - you can check with --examine)
>
> You could fix test_stripe to put the right value in the 'offsets' array,
> or you could create the array with 1.0 or 0.90 metadata.
Hi Neil,
thanks for the info, maybe this should be a second patch.
In the meantime, please find attached a patch to restripe.c
of mdadm 3.2 (latest, I hope).
This should add the functionality to detect, in RAID-6,
which of the disks potentially has problems, in case of
parity errors.
Some checks take place in order to avoid false positives,
I hope these are correct and enough.
I'm not 100% happy of the interface (too much redundancy),
but for the time being it could be OK.
Of course, any improvement is welcome.
Please consider to include these changes to the next mdadm
whatever release.
bye,
Signed-off-by: NeilBrown <neilb@suse.de>
In metadata size is set already during migration initialization.
There is no reason for second /the same/ calculation.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Before reshape finalization migration is still present in metadata.
After patch 'imsm: FIX: crash during getting map'
function get_imsm_map() returns correct value,
this means in our case from second (start) map.
We should calculate map size basing on first (final) map.
For this we should request it by setting second function parameter to '0'
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Array size calculation is made in the same way in few places in code.
Make function imsm_set_device_size() for this common code.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Some debug strings remains as they were introduced,
before code was moved to separate function.
Information displayed by debug information in not all cases
was correct.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
imsm_num_data_members() can indicate error by returning 0 value
In such case size cannot be set based on 0 value.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When a->last_checkpoint variable can reach array end,
reshape finalization can be put in to single place.
There is no need to reset migration variables.
imsm_set_disk() will call end_migration() and this sets
all migration variables to required values.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Calculation of size is almost ok, except concept of blocks.
Size for setting in md has to be divided by 2 to be correct.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When reshape is finished monitor has to set last checkpoint
to the array end to allow metatdata for reshape finalization.
Metadata has to know if reshape is finished or it is broken
On reshape finish metadata finalization is required.
When reshape is broken, metadata must remain as is to allow
for reshape restart from checkpoint.
This can be resolved based on reshape_position sysfs entry.
When it is equal to 'none', it means that md finishes work.
In such situation move checkpoint to the end of array.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When get_imsm_map() is called with second_map parameter == '-1'
and array is not in migration state NULL pointer is returned.
This is wrong. '-1' means return map as migration record points.
'-1' can be passed to get_imsm_map() from imsm_num_data_members().
imsm_num_data_members() is called to get current map members based
on migr_state information
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When the metadata doesn't identify which array a spare belongs to
we normally require an explicit domain match to connect a spare
with an array.
However when the spare is explicitly listed in argv, it should be
safe to include as long as there is no domain conflict.
Signed-off-by: NeilBrown <neilb@suse.de>
Sometime we will need to know the difference between no domains found
and domains didn't match.
So allow domain_test to return different values and fix up all callers
to maintain current behaviour.
Signed-off-by: NeilBrown <neilb@suse.de>
For containers, it is always appropriate to include a device in the
container.
Whether it should then be included in an array is a separate question.
Signed-off-by: NeilBrown <neilb@suse.de>
If we find a device that has not superblock, we currently fail
unless in auto_assem mode.
However we really should only fail if the device was explicitly listed
in the arg list. So add a test for that.
Signed-off-by: NeilBrown <neilb@suse.de>
When there are any arrays in config file the spares with
domain not matching any array are not assembled because
auto assembly is not attempted.
Addition of ARRAY line with uuid=0:0:0:0 in config will work
with modified condition for gathering spares.
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Arrays on partitions are not supported for external metadata
so do not take such spare from native array.
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Too big map was copied (outside allocated memory) and this causes
mdmon crash for 2 raid0 arrays in container.
Map of correct (smaller) size should be copied,
to not overwrite any internal data.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When expansion is run on 2 raid0 arrays in container no update
is sent to mdmon because mdmon is off (mdadm performs update)
Memory size for first reshaped array is allocated to satisfy memory
requirements for expanded maps.
Memory for second device is allocated using old disks number, as in
metadata there is no information about this array reshape.
When mdmon initiates second array reshape it overwrites internal
structures and crashes). There is no place to keep expanded maps.
To avoid this situation during loading metadata, allocated memory
should be performed using the maximum used disks number in particular
container.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When second array reshape is about to start external metadata should
be updated by mdmon in imsm_set_array_state(). For this purposes
imsm_progress_container_reshape() is reused.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Reshape is started from second array, so it causes imsm incompatibility
and problems during second array start.
Reshape should be started in arrays metadata order.
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>