When OLCE is in progress, checkpoint steps are getting bigger due to added space during process.
When mdadm fails after saving "max" to sync_max, mdmon will monitor process
and switch reshape to next array. At this moment we have got information
inconsistency between metadata and migration record.
To avoid this, clear migration record by mdmon /exception from the rule
that migration record is maintained by mdadm/ when reshape switches
to next array.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When reshape is broken it can occur that metadata is not saved properly.
This can cause that reshape process is farther in md than metadata states.
On restart save checkpoint to store current position /probably farther/
that can be read from md.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When chunk size migration occurs (e.g. 128k->4k) first checkpoint cannot
be set in md due to too small step. Correct migration record initialization
to allow whole copy area usage and increase migration checkpoint step.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When during incremental assembly general migration is in progress,
starting degraded array causes that no more disks (even present)
can be added later as array is already started.
Request all previously present disks during general migration for assembly.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Fix the case with creating an array with given container in command line
instead of real devices:
mdadm -CR /dev/md/raid0 -l 0 -n 2 -z5G /dev/md/imsm
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
IMSM OROM limits number of volumes per controller. Volumes
above the limit are blocked in OROM. mdadm should follow OROM limitations
in this area. Therefore we need to count number of volumes on the devices
attached to SATA (ahci driver) or SAS (isci) controller. Adding a new volume
must be blocked if the number of volumes on devices attached to the given
controller is exceeded.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This option is going to be used to load and analyse the metadata from
devices. This is needed to count the number of volumes on devcies attached
to particular Intel controller (SATA or SAS). It shall be done without
activation of container and volumes on the devices.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Prepare function for subsequent changes related to
loading metadata from devices list.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The printed messages should be more appropriate and understandable
for user. If maxsize is equal 0, this means there is no free space left
on device. If size is greater than maxsize, this means there is not enough
space to create a new volume of given size.
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Make test for all sub arrays having the same number of devices
dependant on the option ROM requirements being checked.
08imsm-overlap disables the OROM check but then fails because this
test causes it to.
Reported-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This fields doesn't work any more as ->getinfo_super clears the info
structure at an awkward time. So get rid of it and do it differently.
The issue is that the metadata handler cannot tell if the uuid it has
was randomly generated or explicitly requested, except on the first
call.
And we don't want to accept explicit requests for IMSM.
So when it was auto-generated, make it look distinctive by having the
same int copied in all 4 positions. If someone requests a uuid like
that, I guess they get away with it.
Reported-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Chunk size only migration for raid0 and raid5 is not possible.
(mdadm UT 15* fails). Mdadm exits with information:
mdadm: imsm unknown layout 0xffffffff for this raid level 0
Problem was introduced in patch (2011-11-16):
imsm: platform capabilities are not validated during level migration
During chunk size migration layout variable is not set correctly.
Set it correctly for this migration type.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
load_imsm_migr_rec() should see difference between no migration record due
to no migration in progress and loading migration record error.
Additional return value (-2) was introduced to this function.
Using new status load_super_imsm_all() can correctly check loading
migration record status.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
make everything doesn't compile (again) due to not used function warning
and uninitialized variable.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Add definition:
MIGR_REC_BUF_SIZE
MIGR_REC_POSITION
to super-intel.c and do not use magic numbers
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This patch is addition to patch:
"imsm: FIX: Limit migration record operation by disk slot not by index"
Location of migration record (2 first slots) should be taken on up to date
information. It is in first map.
Change slot verification to use first map only.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
imsm should store migration record in to 2 first disks in array.
This should be evaluated based on disk slots, not on disks index.
It is not guaranteed that indexes are equal to slots.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Maps should not be accessed using "magic numbers" /0, 1,-1/.
Add proper definitions and change all map access to use them.
Change present definitions /MAP_0/MAP_1/ to values already used
in code /0, 1, -1//
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When changes are made to 2nd map, slot in second map should be tested
instead first one /as change will be applied to second map).
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When missing device is handled for rebuild or initialization
end_migration() should be called to merge ords in case additional
degradation.
I've removed this call to end_migration() as it was called
for migration also.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Allow for marking failures in second map during rebuild and initialization
also (not during migration only)
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
During initialization disk failure can occur also. Add code for such case
in imsm_set_disk() to support such event.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Do not allow for spare device activation while rebuild is in progress,
when additional degradation occur.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Rework is needed to map state transition part to allow easier code reading.
After rework it is easy to find out what can happen in what map state
transition.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Ord's merging should occur when rebuild finishes and final state is other
than expected only /additional failures occur during rebuild/.
Exclude array initialization.
Merging ords on migration finish should never happen.
Any failure during migration should be immediately placed in first
/current/ map, so no merge is necessary.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
We shouldn't use longer map. mdadm should know what map is accessed
at the moment.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When mdadm is compiled using e.g. 'everything' option, mdasseble
compilation is broken.
Change code to enable mdasseble compilation
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When redundant array (e.g. raid5) is created metadata shows it is in
normal state. Initialization process is showed in metadata as rebuild from normal
to normal state. Redundant array should be initially in uninitialized state
before it's initialization.
Add code to put array in uninitialized state upon array creation.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Any degradation during backup recovery causes error and array assembly
failure.
Allow for degradation during backup recovery.
This allows for degraded array assembly.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Any degradation during opening any backup device can causes error
and array assembly failure.
Allow for degradation during opening backup devices.
This allows for degraded array assembly.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
imsm_count_failed() assumes that on the same positions in both maps
the same disk indexes are kept. This is not always true /e.g. rebuild/
It can occur that disk taken for rebuild fails at once.
Degradation on the same positions in both maps refers to different disks.
Sum of both ords can point on not failed disk. This can cause wrong
failed disk counting.
Check both maps independently. This allows for getting real degradation
information.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When degradation during migration occurs second map state is not set
to degraded value (map are updated correctly).
Correct second map state according to it's degradation level.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When during assembly degradation occurs restoring metadata critical section
fails whole assembly.
Allow for degradation during assembly and not restore data on degraded disk.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
It can occur that degradation during migration occurs on disks that are not
present in both maps /e.g. degradation on just added disk during OLCE/.
This can cause that maps will be in different states (one will be in degraded
and second in normal state). In such situation getinfo_super_imsm_volume()
will not return migration information.
Remove single state limitation in both maps to allow migration information
retrieving.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Currently mdadm for IMSM can finalize not-degraded migration only.
Add support for IMSM for migration finalization when array
are is degraded state.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Currently when degradation occurs migration is finalized. This is wrong.
Finalizing migration when it is not finished can lead to data corruption
after next array assembly.
Do not finish migration when degradation occurs.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
During migration degradation is set in first map only. This means that
according to second map disk is present. This is not true and not compatible
with OROM behavior.
Set disks in both maps to degraded state during migration.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When 2 maps are present, IMSM can use shorter map for setting disk
in to degraded state. It can happen that degraded disk can be not present
in shorter map.
We should use longer map for setting disk in to degraded state.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Incremental in some cases prematurely assembles degraded arrays due to
wrong index used in code which counts missing disks
Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
The value of blocks per migration unit is not printed correctly
when the metadata's content is examined using -E option on disks
without present migration record. (Migration record is present only
on 2 first disks in array due to IMSM compatibility restrictions.)
Printing the value of blocks per migration unit was corrected.
It is printed as N/A (Not Available) for disks
without the migration record.
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Migration from RAID0 to RAID5 should be blocked on the system without
support for RAID5. No platform validation was performed in RAID
level migrations: verification for all level migrations added.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The problem occurs when RAID10 array under rebuild
(after one disk fails) is assembled incrementally.
Mdadm tries to start array just after adding the third disk
and the volume is assembled incorrectly (in degraded state).
The cause is that container_enough depends on
newly missing disks which are checked incorrectly now.
They should be checked using always the first map.
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
mdadm allows to create second volume on the same disk set, whose size is
less then the free space left in the container (with IMSM_NO_PLATFORM
undefined or set to 0). This is an OROM compatibility issue.
It is fixed by verifying whether IMSM_NO_PLATFORM is set and for
the second volume creation scenario, requested size is verified against
remaining available space.
Signed-off-by: Lukasz Orlowski <lukasz.orlowski@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The problem occurs when array under OLCE (from 3 to 6 disks)
is assembled incrementally. Mdadm tries to start array
just after adding the third disk (this is equal to the number of disks
before the start of reshape). It does not succeed,
the volume does not assembly correctly.
The function counting failed disks (imsm_count_failed())
was fixed for migration case. Now all disk members in both maps
are checked when failed disks are counted correctly.
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Jes Sorensen
Adam Kwolek
Labun, Marcin
Lukasz Dorau
Williams, Dan J
NeilBrown
Przemyslaw Czarnowski
Lukasz Orlowski