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 problem occurs when array under migration is assembled incrementally.
st->update_tail is not initialized in function
assemble_container_content() and during reshape
the checkpoint information in metadata is not being updated.
The value of st->update_tail is now initialized in function
assemble_container_content() and during reshape the checkpoint
information in metadata is being updated correctly on all disks.
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
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>
mdadm allowes to assemble 2 volumes with the same names based on the
config file. The issue is fixed by iterating over the list of md device
identifiers and comparing the names of md devices against each other,
detecting identical names and blocking the assembly should the same names
be found.
Now having detected duplicate names, mdadm terminates without assembling
the container, displaying appropriate prompt.
Signed-off-by: Lukasz Orlowski <lukasz.orlowski@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When mdmon is absent metadata is not updated, and container_reshape()
can fall in to endless loop. This can cause user data corruption.
In case when mdmon is absent do not continue container reshape process.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
It possible that we try to use victim_sock even when we couldn't open
it. This is never actually harmful but it looks wrong and it is best
to fix it.
Signed-off-by: NeilBrown <neilb@suse.de>
This reverts commit 819c158866.
Adam Kwolek reports that with this patch, mdmon sometimes doesn't start:
When array is not clean dismounted directory /dev/.mdadm is not cleaned up.
On array re-assembly read pid is not valid and it is not possible
to connect to monitor. This causes mdmon to exit and array remains
not monitored.
Problem is introduced by fix:
mdmon(): Error out if failing to connect to victim monitor
819c158866
This is critical for container reshape when mdmon is should finish reshape.
when reshape is not finished, array is reshaped again by mdadm.
As victim_sock is subsequently tested, we don't really need to test-and-fail here.
Reported-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Extracting the 'subarray' arg for these options was being done at the
wrong place which lead to the code being a bit confusing and looking
wrong.
So reformat that code a bit better and move the extraction of
'subarray' down to the main parsing of these options rather than the
mode setting.
Signed-off-by: NeilBrown <neilb@suse.de>
Silencing gcc's warning of uninitialized variables was hiding a bug
where if we have /dev/md64 as a symlink, and /dev/md64p1 was a real
device node.
In this case major_num and minor_num would not get populated, but we
end up comparing against them because the stat for md64p1 succeeds.
Instead of using the int foo = foo trick, change the code to set
set the variables to invalid values so comparisons will fail.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Adam Kwolek
Przemyslaw Czarnowski
Lukasz Dorau
Labun, Marcin
Lukasz Orlowski
NeilBrown
Jes Sorensen