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>
check_reshape should not try to parse the subarray string - only
metadata handlers are allowed to do that.
The common code and only interpret a subarray string by passing it to
"container_content" which will then return only the member for that
subarray.
So remove check_reshape and place similar logic explicitly at the two
call-sites. They are different enough that it is probably clearer to
have explicit code.
Signed-off-by: NeilBrown <neilb@suse.de>
In case of second posix_memalign() failing, release memory allocated
in first posix_memalign() call.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
container_content retrieves volume information from disks in the
container. For unsupported volumes the function was not returning
mdinfo. When all volumes were unsupported the function was returning
NULL pointer to block actions on the volumes. Therefore, such volumes
were not activated in Incremental and Assembly. As side effect they
also could not be deleted using kill-subarray since "kill" function
requires to obtain a valid mdinfo from container_content.
This patch fixes the kill-subarray problem by allowing to obtain
mdinfo of all volumes types including unsupported and introducing new
array.status flags.
There are following changes:
1. Added MD_SB_BLOCK_VOLUME for blocking an array, other arrays in the
container can be activated.
2. Added MD_SB_BLOCK_CONTAINER_RESHAPE block container wide reshapes
(like changing disk numbers in arrays).
3. IMSM container_content handler is to load mdinfo for all volumes
and set both blocking flags in array.state field in mdinfo of
unsupported volumes. In case of some errors, all volumes can be
affected. Only blocked array is not activated (also reshaped as
result). The container wide reshapes are also blocked since by
metadata definition they require modifications of both arrays.
4. Incremental_container and Assemble functions check array.state and
do not activate volumes with blocking bits set.
5. assemble_container_content is changed to check container wide reshapes
before activating reshapes of assembled containers.
6. Grow_reshape and Grow_continue_command checks blocking bits
before starting reshapes or continueing (-G --continue) reshapes.
7. kill-subarray ignores array.state info and can remove requested array.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
gcc 4.6.1 doesn't like calculating a variable that then isn't
used. Remove it.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
After migration from Raid 0 to Raid 10, the metadata is incorrect,
leaving one mirror disk marked as spare and one missing disk as a member
of the array.
The reason is that the metadata update code for spare activation
procedure takes into account one spare disk only, not checking
the following ones.
Signed-off-by: Lukasz Orlowski <lukasz.orlowski@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The metadata update code during spare activation is moved to a separate
function for clarity of code, as a prework for the next patch fixing
the bug.
Signed-off-by: Lukasz Orlowski <lukasz.orlowski@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The volume's name is saved in the array of chars.
All elements of the array can have nonzero values
and the next byte in memory does not have to have
the value of 0, so one must be cautious when
printing out the volume's name.
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Using an array of chars without the terminating null byte
as a parameter of sprintf() function causes segfault
when dealing with SAS drives (with 20-digits serial number).
The memcpy() function is used instead.
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
readlink() returns the number of bytes in the buffer.
If we do something like
len = readlink(path, buf, sizeof(buf));
buf[len] = '\0';
we might write one byte past the end of the buffer.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For 'resync' besides the update of migration type (imsm_vol.migr_type
structure) additionally status (imsm_dev.status) flag is set to
DEV_VERIFY_AND_FIX. In order to clean up after migration, status flag
must be cleared. For this reason, migration type shouldn't be set
directly but via set_migr_type(). Otherwise status does not reflect
the state of array.
Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
During activation of spare disks, only one of all available
spare disks can be activated at this moment.
It causes that for example during take-over from
RAID0 with 2 disks to RAID10, only one of two spare disks
is taken for recovery and a degraded RAID10 array
with only 3 of 4 working disks is created.
It has been fixed by adding more than one of all available
spare disks and saving them in additional_test_list
which is passed to imsm_add_spare().
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If any reshape in container is active set recovery_blocked field.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
During reshape, resync/rebuild in the same container is not possible
due to fact that all arrays in container has to share the same disks set.
Block new resync/rebuild process initialization and setting resync_start
to 0 while any reshape in container is active. This avoids breaking
container reshape and doesn't allow for starting multiple processes
/resync/rebuild and reshape/ at the same time in md.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Spare disk activation or starting repair for one array while on second
reshape is in progress, will lead to IMSM incompatible situation when
2 arrays in container shares different disks sets.
This can cause that 2 processes in container /reshape and rebuild/
are in progress in parallel. This is IMSM incompatible situation also.
Block spare disk activation and starting resync if any reshape in container
is in progress.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
New function to calculate minimum reservation to expect from a spare
is introduced.
The required amount of space at the end of the disk depends on what we
plan to do with the spare and what array we want to use it in.
For creating new subarray in an empty container the full reservation of
MPB_SECTOR_COUNT + IMSM_RESERVED_SECTORS is required.
For recovery or OLCE on a volume using new metadata format at least
MPB_SECTOR_CNT + NUM_BLOCKS_DIRTY_STRIPE_REGION is required.
The additional space for migration optimization included in
IMSM_RESERVED_SECTORS is not necessary and is not reserved by some oroms.
MPB_SECTOR_CNT alone is not sufficient as it does not include the
reservation at the end of subarray.
However if the real reservation on active disks is smaller than this
(when the array uses old metadata format) we should use the real value.
This will allow OLCE and recovery to start on the spare even if the volume
doesn't have the reservation we normally use for new volumes.
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When validate_geometry finds that we haven't committed to
a metadata yet and that the subdev is a member of 'our'
container, it needs to report any errors it finds as Create()
cannot report them effectively.
So make a slight change to the semantics of the 'verbose' flag
and allow validate_geometry to report if it printed any error
messages.
Signed-off-by: NeilBrown <neilb@suse.de>
Allows to create RAID 5 volume on 3 disks and then RAID 1 volume on 2
disks withing the same container.
Signed-off-by: Lukasz Orlowski <lukasz.orlowski@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Takeover marks disk as failed and adds to serial ':0' string and then
turns it in to spare. This causes that when new spare is about to be used,
it cannot be found due to different disk serial number.
Restore disk serial number to avoid this problem.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Specifying missing devices at create is very useful for array recovery.
For imsm create dummy disk entries at init_super_imsm time, and then use
them to fill in unoccupied slots in the final array (if the container is
unpopulated).
If the container is already populated (has a subarray)
'missing' disks must be in reference to already recorded missing devices
in the metadata.
Also add support for --assume-clean for imsm arrays.
Cc: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Different OROMs reserve different amounts of space for the migration area.
When activating a spare minimize the reserved space otherwise a valid spare
can be prevented from joining an array with a migration area smaller than
IMSM_RESERVED_SECTORS.
This may result in an array that cannot be reshaped, but that is less
surprising than not being able to rebuild a degraded array.
imsm_reserved_sectors() already reports the minimal value which adds to
the confusion when trying rebuild an array because mdadm -E indicates
that the device has enough space.
Cc: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Commit 94827db3 "imsm: add spares to --examine output." may try to
display failed disks whose imsm_disk info is not uptodate (due to not
being able to look itself up by serial). The same effect can be had by
just loosening the restriction in print_imsm_disk().
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
We already refrain from updating metadata on disks that are failed at
load, need to do the same for new failures. This also reverts b4add146
as we *do* want to update other disks' view of the failed device as out of
date.
Cc: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Validate geometry is incorrectly looking at max disks support which is
irrelevant for md/mdadm. ->dpa (disks per array) is how many disks the
orom will allow per volume.
Also cleanup an unnecessary ->orom check, is_raid_level_supported()
already does the right thing in the !orom case.
Cc: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Some bits are not handled by mdadm, but their presence should not
cause failure.
In particular MPB_ATTRIB_NEVER_USE appears harmless.
Reported-by: Thomas Steinborn <thestonewell@googlemail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The 'raid_disk' can be different to the 'number' and must be
the position of the device in the array, not in the container.
Normally these should not be different, but the test-suite creates a
possibility so it should work.
Signed-off-by: NeilBrown <neilb@suse.de>
Set a valid default in the !orom case, otherwise we segfault, or
otherwise fail.
Cc: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
getinfo_super_imsm_volume doesn't correctly set info.disk fields
because it doesn't know which disk to set them from.
It should be the last disk passed to add_to_super.
So add a field 'current_disk' to record this disk in add_to_super, and
use it in getinfo_super.
This allows us to remove a hack in Create.c
Signed-off-by: NeilBrown <neilb@suse.de>
This patch fixes these build issues:
super-intel.c: In function 'getinfo_super_imsm_volume':
super-intel.c:2327:4: error: format '%llu' expects argument of type 'long long
unsigned int', but argument 3 has type '__u64' [-Werror=format]
super-intel.c: In function 'imsm_reshape_super':
super-intel.c:8665:7: error: 'devnum' may be used uninitialized in this function [-Werror=uninitialized]
Signed-off-by: Milan Broz <mbroz@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The serial number is not necessarily nul terminated, so we need to be
sure to only use the allowed number of chars.
Signed-off-by: NeilBrown <neilb@suse.de>
Reported-by: Arvin Schnell <aschnell@novell.com>
IMSM's meta data contains Attributes field that contains information about
supported features.
To assembly an array mdadm has to support all features specified by attributes.
The patch introduces new attributes support and validation of the attribuses
during an array assembly.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When array size is not aligned to copy area, number of migration unit
is increased in init_migr_record_imsm():7665 to reshape whole array.
During calculation of last migration unit, this should be in mind also,
otherwise checkpoint (max-1) is always written and reshape
is never finished in mdadm.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Pointer dev2 passed in write_super_imsm():4451 can be equal to NULL.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When target_offsets allocation fails execution goes to abort label,
where elements from targets table are closed.
Initialize targets table after allocation.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When array raid0 is migrated to raid5, reshape cannot be continued
correctly due to wrong array parameters settings.
Raid disks number is set too big.
There is no need, during raid0->raid5 migration to increase
info->array.raid_disks, it is already set to final value using
designation map information.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Sporadicaly when Raid5's data are restored from backup area,
corruption occurs.
It doesn't happen if reshape process is beyond critical section.
Root cause of the problem is passing wrong starting point in
restore_stripes(). It was hard coded to 0 so far.
This causes that parity disks position in first stripe was always set
to the last raid disk. This position should depend on data position in array.
Proper start position was set and pointer for restoring data
(copy area address) is adjusted to passed start parameter.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
mdmon cannot rollback metadata changes automatically.
It can break reshape process in the way that in case of reshape break
user will not be able to deal with broken reshape due to lack of information
about reshape geometry.
mdadm (process that invokes reshape) doesn't make any rollback to allow
for user action. mdmon should not do this either unless it knows for sure
it is save. such knowledge is not available for automatic rollback.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Function imsm_level_to_layout() should be use to get array layout.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When no reshape backup is required (e.g. OLCE after critical section),
check-pointing can use bigger steps than backup space allows for.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Timeout should not be used for select function in wait_for_reshape_imsm().
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This function needs to be corrected.
It should check sysfs operations status and it should not interpret
0 reshape position special meaning.
Unused input parameter is removed also.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When backup exists in copy area reshape cannot be continued.
In such situation, array is in unstable state.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Unused variables and code can be removed from imsm_manage_reshape()
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When array under reshape is assembled, reshape position used in sysfs_set_array()
should be set to position after recovered from backup area.
This avoids data corruption due to reshape the same array area again.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Detect in recover_backup_imsm() if not opened disks number is smaller
than allowed degradation for given raid level. This allows for reshape restart
on degraded array.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For raid0 reshape imsm uses degraded raid4 for this operation.
Using real raid level (raid0) for stripe calculation causes no need
for parity calculation and can speed up reshape process.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
new_data parameter is not used in save_backup_imsm().
It is removed from function interface.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
imsm_manage_reshape() should not shift start copy position.
This offset is passed to manage reshape function /and it is used/
as input parameter in offsets table already.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Parameters that are not used by imsm_manage_reshape() should not cause
failure of this function.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When user doesn't specify raid 5 layout for raid0->rai5 migration,
layout structure member is uninitialized. Earlier it cannot be determined
if it is correct or not.
In metadata handle proper verification is placed.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When rounded array size information from metadata is used for number
of migration units calculation it can occurs that result of units
can be smaller (-1) than required due to used (rounded) array size).
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Checkpoint should be saved when migration is in progress only.
End of reshape (based on passes status) should be detected and it should
not cause abort of reshape/check-pointing/ operation.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Migration compatibility can be checked when general migration record
is present.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
container_content_imsm was setting info->next before calling
getinfo_super_imsm_container which now zeros everything.
So move that assignment to afterwards.
So both imsm and ddf were assuming info->disk.raid_disk means
something but it doesn't. So fix those.
Signed-off-by: NeilBrown <neilb@suse.de>
imsm's arrays supports imsm native check-pointing now.
User warning is no longer required.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
mdmon has to update checkpoint information in metadata during
general migration according to received metadata update.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
mdadm has to prepare checkpoint information update and send it to mdmon.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
There are 2 places for keeping checkpoint information:
- metadata (per volume information used during volume
initialization and rebuilding).
- migration record (per container information used during
migration/reshape)
During reshape both checkpoints has to contains the same information.
To do this mdadm will send metadta update with checkpoint information.
Note: Checkpoint information consistence is not critical. During general
migration restart, information from migration record is used only.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
imsm contains 2 check-pointing mechanism. One (per array) is used for
initialization and rebuild and second (per container) is used for general
migration (reshape). First is controlled by mdmon, second by mdadm.
To avoid conflicts disable mdmon checkpoints updating for general
migration.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Add ability to restore data backed up in General Migration Copy Area
in case of unexpected reshape interruption.
Function restores data during an array assembly and then reshape
is continues from next checkpoint.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
blocks_per_migr_unit() has to use information from migration record
for general migration case. This causes to pass intel_super pointer
to this function and some other interfaces changes.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Add ability to display information from migration record in examine
option.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When metadata is saved and there is no general migration in progress
/in container/ clear migration record in container.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Before reshaping every "migration unit", check if array is still usable.
In failed disks number is greater than allowed degradation level, reshape
has to be aborted.
Signed-off-by: Maciej Trela <maciej.trela@intel.com>
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Before reshape is started, mdadm should check again if there is only one
array (in container) under reshape. Then function "divides" array in to
"migration units" that can fits migration copy area and enters main loop.
It checks if current "migration unit" requires to be backed up.
If necessary mdadm saves it to copy area and updates migration record.
Then MD-driver is directed to perform reshape step (by "migration unit" size)
and checkpoint is moved forward. In this way reshape is executed until
array ends.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
After each checkpoint mdadm should set new reshaped area and wait
until md finishes reshape. Function wait_for_reshape_imsm() sets
new reshape range and waits for job completion.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Under Windows IMSM can reshape arrays in 2 directions
(ascending and decsending).
Under Linux one (ascending) direction is supported at this moment.
Block loading metadata when decsending reshape is detected
Windows also uses optimalization area during reshaping array.
Linux does not support it.
The patch blocks this operation also.
Signed-off-by: Maciej Trela <maciej.trela@intel.com>
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This patch adds methods of manipulating migration record:
init_migr_record_imsm() - initiate migration record at the beginning of
the reshape process
write_imsm_migr_rec() - saves migration record to array.
Migration record is stored on 2 first disks in array only.
save_backup_imsm() - saves critical data stripes to Migration Copy Area
and updates the current migration unit status.
Uses restore_stripes() to format a destination stripe, and to write it
to the Migration Copy Area.
save_checkpoint_imsm() - Updates the current unit status in the
migration record.
Migration record is written to 2 first array disks only (similar to reading
operation).
Signed-off-by: Maciej Trela <maciej.trela@intel.com>
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
IMSM for securing reshape process uses special disk area outside metadata
for reshaped area backup purposes. If just reshaped array area requires
backup, bunch of array stripes prepared for reshape is stored in to
Migration Copy Area. In case of reshape interruption, Option ROM during
restart or mdadm during reshape restart (when no reboot occurs) will
restore Migration Copy Area to designation array. Reshape can be
continued from stable array stable state.
This patch adds support for IMSM migration record structure.
IMSM migration record is stored on the first two disks of IMSM volume
during the migration.
Add function for reading migration record, so mdadm can read (if present)
migration record. Migration record has to be cleared every time
MIGR_GEN_MIGR is started.
Signed-off-by: Maciej Trela <maciej.trela@intel.com>
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Some code currently clears 'info' before calling getinfo_super,
some code doesn't.
To be consistent, change it so no caller ever clears 'info',
but ever getinfo_super function must clear it.
Note that ->raid_disk may be meaningful if that 'map' is passed
non-NULL. In that case it is copied out before the structure
is zeroed.
Signed-off-by: NeilBrown <neilb@suse.de>
Put information about new chunk size change in to migration metadata
update allowing simultaneous level change and re-striping.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Received update and prepared memory is processed to update imsm metadata.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When level is changed from raid0 to raid5 memory is required for replace device
smaller device/array object.
This memory is allocated in manager context in prepare_update()
Prepare_update() is called in manager context so memory allocation are
allowed here. This allows us to look for spare devices for meta update.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
it is not supported yet, so start such transition is improper.
Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Introducing raid0->raid5 level migration metadata update structure
is prepared for future use.
Adding spare device is required to hold additional raid5 parity.
Mdadm just checks for spares, but it is not included in update.
If there are no spares available, abort. Otherwise we will create
degraded array what should be not allowed.
Mdmon will decide what spare device is used for parity.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When 2 arrays are configured in container and arrays are reassembled during
rebuild or initialization, checkpoint for one array can be reset. It depends
on arrays assembly order.
Scenario:
1. Create 2 arrays (e.g. raid5)
2. Add spare to container
3. Degrade arrays /rebuild starts on array #1 and continues to n%/
4. Reassembly arrays
5. Rebuild starts on array #2 /because of assembly order/ from 0%
6. On first checkpoint stored for array #2 (non 0 value), checkpoint
for array #1 is cleared /it is delayed rebuild in md, so progress is 0/
7. Rebuild on #1 starts from n% /it was configured before checkpoint
was cleared/.
Any next reassembly during rebuild of #2 array (after p.6) causes
checkpoint information lost for array #1.
Solution is not store checkpoint for progress == 0.
Checkpoint is set to 0 when rebuild/initialization starts.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
To behave in the similar way as native metadata during migration,
new raid disks number has to be reported by metadata handler.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
OROM can create array with chunk size not aligned.
To resolve this problem in mdadm, metadata handler has to report
component size aligned value for mdadm operations
while metadata value stays unchanged.
Do not correct alignment for raid1 and in error case.
Correction allows check in analyse_change() (Grow.c:905) to pass.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
It can occur that OROM creates array not aligned properly.
Expansion cannot be run in such cases. It is detected in analyse_change().
It is too late. This causes that metadata is in migration state already,
when expansion cannot be started.
This problem has to be detected before metadata is updated,
in all arrays in reshaped container.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Current check-pointing implementation doesn't allow for interrupting reshape of boot arrays
due to checkpoint restore has to be done before system start.
There is problem with passing backup file name to array automatically mounted during boot time,
especially when scan mode is used.
Until IMSM check-pointing implementation will be introduced, warning about reboot risk
should be placed in mdadm.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This patch rollback one change connected with mdadm-OROM
compatibility:
adding ':0' at the end of disk serial number if disk is
detected as failed.
Current mdadm's implementation does not distinguish two
cases when disk is marked as failed:
1. If disk is really failed- disconnected, broken
2. Just marked as failed by mdadm- using "-f" option
Second case is not yet fully handled and compatible with
IMSM standard.
Changing serial number of existing, operational disk causes
problems in "thunderdome" and "load_super" functions that use
serial numbers to disks comparisons and searching.
The change must be recalled until full support will be
developed.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Honor ignore_hw_compat to load metadata from disk attached to non-IMSM
controller or when there are no IMSM OROM/EFI capabilities.
Used only for guessing and examining metadata format.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
During adding spare disks to raid0, spare metadata is not written.
This is due to exit form sync_metadata() on empty updates_pending flag.
When mdmon is absent indicate sync_metadata() to flush changes to disks.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
While last_checkpoint is counter in per disk units, checkpoints
should be stored in the same manner.
Restoring from checkpoint should should recalculate checkpoint in to
array position (reshape_progress).
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
mdadm has a convention in some areas of passing a device name
if error messages about it are interesting, or NULL if not.
Follow this convention with find_intel_hba_capability so that it
doesn't complain when not appropriate - and so that it doesn't
have to go and find a device name that it wasn't given.
Signed-off-by: NeilBrown <neilb@suse.de>
OROM/EFI capabilities are retrieved based on disk's controller type.
1/ alloc_super no longer retrieves OROM capabilities
2/ find_imsm_capability replaces find_imsm_orom
3/ new function find_intel_hba_capability gets disk's HBA and relevant
capability
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Function find_intel_hba_capability attaches HBA information
to intel_super structure based on fd of the component disk.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
compare_super_imsm verifies that the component disks use the same type of HBA
in platform dependent environment. Otherwise print-out error message and block
the action.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Arrays exceeding the OROM/EFI maximum number of supported disk are
blocked in validate_geometry_imsm_orom function.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Print-out error message when volume geometry fails to comply with
OROM/EFI controller's capabilities.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Container_content_imsm calls validate_goemtry_imsm_orom to verify that
the array parameters are supported by controller's OROM/EFI.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The function uses find_intel_device and find_imsm_capability to present
AHCI and SAS controller capabilities taken from OROM or EFI.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
During reshape for dirty volumes reshape_progress has to be calculated
also. To keep the same logic for array creation:
not setting info->resync_start = MaxSector when first condition is
true,
resync_start is initialized by MaxSector to allow proper array
initialization.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Array state has to be managed during reshape based on consistent flag.
To achieve this existing code will be reused. Currently existing code for
blocks_per_unit calculation can be removed
and existing code can be reused also.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
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>
Variables declaration moved a little bit up,
to not mix declaration and code.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For general migration, blocks per unit are required for all disks,
not for per-member.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If a reshape (migration) is happening, we might need to modify the information
with provide to md so that it can cope with the reshape.
For example, if a migration from 4-device RAID0 to 5-device RAID0 is
happening, we need to tell md that it is reshape from degraded
5-device RAID4 to degraded 6-device RAID4 so md doesn't handle direct
reshape of RAID0.
There may be other migrations supported by IMSM that need special
treatment here.
Signed-off-by: NeilBrown <neilb@suse.de>
When we cannot find spare devices for grow operation we should
print error message.
This patch changes debug error message to 'stderr' print.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Defect description:
When we create an redundant array in mdadm and then degrade it
by disk removing, Option ROM and Windows OS does not detect any array.
Reason:
Metadata created and updated after degrading array is not compatible
with IMSM standard.
This patch synchronizes the metadata according IMSM requirements.
Following inconsistencies have been fixed:
- reset all fields in imsm_dev during creation to avoid random values
- init dev status during creation to proper state
- not reset CONFIGURED_DISK flag when disk is missing
- add ":0" suffix to the serial number for missing/failed disks
- update medatada signature after takeover operation
- mark map state as degraded after raid0->raid10 takeover
Note:
Patch reworked after Dan Willams review.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When reshape is started imsm stores new size in metadata.
mdadm requires "old" size to proper initialization restarted array.
When reshape is in progress getinfo_super_imsm_volume() should report
computed array size value instead array size stored in metatda.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
reshape prodess cannot be restarted due to no checkpoint information
in mdinfo.
When metadata is read during reshape process or reshape restart,
rehape_progress (mdinfo field) has to be initialized to value
stored in metadata. This allows start reshape from stored
in metadata checkpoint.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When chunk size is not set from command line we need to guess it
depending on metadata given on command line or found on listed devices.
Validate_geometry sets the default for it's metadata if chunk is not set.
For external metadata chunk is set only when creating in a container.
For imsm validate_geometry_imsm_orom is responsible for finding default
chunk depending on container metadata loaded. Container will already know
which controller it is attached to, and have this controllers orom
available.
do_default_chunk indicates that we need to find default chunk and
if validate_geometry fails for some metadata it tells us to reset chunk
that may have been set.
Current solution would set default chunk correctly for imsm only if
container device was given on command line. With the list of devices
chunk was always set to 512.
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
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>
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>
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>
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>
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>
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>
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>
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>
Adding spare disks to imsm container fails due to problem with writing
new_dev to sysfs. This problem was caused by not closed handle
(opened exclusively) in Manage.c:803.
Disk handle was not closed by free_imsm().
This is due to not released disk_mgmt_list in free_imsm_disks().
Proper release of imsm metadata allows for spare adding without problems.
Memory leak was fixed also.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
imsm_reshape_super() currently allows for expansion when requested
raid_disks number is the same as current.
This is wrong. Existing in code condition is too weak.
We should allow for expansion when new disks_number is greater
than current only.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
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>
get_disk_controller_domain recognizes Intel (R) SAS controller (isci).
The function returns three different strings that differentiate disk attached
to AHCI, ISCI or unknown controller types to create separate domains
for each case.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Added support in detail_platform_imsm for Intel (R) SAS controller.
Function supports AHCI and ISCI controllers. RAID properties are derived
from common OROM for both types.
Based on code From: Artur Wojcik <artur.wojcik@intel.com>
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Pull out the AHCI specific parts of detail_platform_imsm to separate functions.
Introduce support new types of controllers.
Based on code From: Artur Wojcik <artur.wojcik@intel.com>
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
add_to_super_imsm handler is able to recognize new type of controller.
It stores the controller information in its structures and blocks
mixing of different controller type in the same container.
In this way it maintains compatibility between Linux and Windows IMSM RAID
stacks. IMSM metadata does not allow arrays to span on devices attached to
different storage controllers.
Based on code From: Artur Wojcik <artur.wojcik@intel.com>
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Number of failed disks MUST be half of initial number of disks.
If number of failed disks is different we should not update
metadata- data corruption may occur after array reassemlation.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Implementation of raid0->raid10 takeover metadata update
at process_update level.
- We are using memory previously allocated in prepare_update to
create two dummy disks will be inserted in the metadata and
new imsm_dev structure with expanded disk order table.
- Update indexes in disk list
- Update metadata map
- Update disk order table
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Allocate memory will be used in process_update.
For raid0->raid10 takeover operation number of disks doubles
so we should allocate memory for additional disks
and one imsm_dev structure with extended order table.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Create metadata update for raid0 -> raid10 takeover.
Because we have no mdmon running for raid0 we have to
update metadata using local update mechanism
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@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>
We previously closed all 'fds' associated with an array in
write_init_super .. sometimes, and sometimes at bad times.
This isn't neat and free_super is a better place to close them.
So make sure free_super always closes the fds that the metadata
manager kept hold of, and stop closing them in write_init_super.
Also add a few more calls to free_super to make sure they really do
get closed.
Reported-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Function intended to use for single volume migration.
Function analyze transition and validate if it is supported.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Function has been divided into two clear parts:
1. Container operations
2. Volume operations
Prototype of imsm_analyze_change function has been added.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Field info->array.spare_disks is used on begin of reshape_array() to
check if there is enough number of spares to process reshape. During
container_content_imsm() call spare disks are not counted. This
causes that reshape_array() reports that there is not enough spares to
execute reshape.
Patch adds spares counting for reshape process.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When process_update() replaces memory for bigger devices, old memory
areas are collected in a list and has to be assigned in to pointer in
update for later release.
List created from old devices is created and attached to space_list
for later releasing.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Local update is performed based on created update, so this code can broke
local update and it is not necessary as prepare and process update functions
are used.
Code removed.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When update is created by mdadm, local information should be updated
also. This makes us to prepare one update for mdmon and second
"update" to maintain local changes. we can use prepared update for
"local/mdadm" metadata update purposes.
We have 2 cases:
1. when metadata is updated by mdmon, we avoid metadata reloading in
mdadm.
we proceed the same updtate 2 times:
- one time in mdadm for "local update"
- second time in mdmon for real metadat update
2. when metadata is updated by mdadm (no mdmon running) updates are
processed in the same way.
- one time in mdadm for "local update"
- there is no "second time" update but mdadm just flushes
metadata to array
This let us to avoid code duplication by using prepare and process
update functions as for update via mdmon. This makes update
preparing mdmon independent and there is no need to maintain the
same thing in 2 places in code.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Only one spare is passed in update.
When more than one disk is added first spare is passed multiple times.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Slot was set based on anchor information.
Disks information was copied outside disk list area.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Based on status information disks are added to array during grow (in reshape_array()).
This information currently is not present and all disks (old and new) were added to md.
To avoid adding already present disks, disk.state has to be set.
Signed-off-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>
As raid4 is not supported by imsm (this is takeovered raid0)
do not fix degraded raid4 arrays.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When raid0 reshape is performed metadata has to be applied by mdadm.
(without mdmon)
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For code reuse in raid0 reshape case when monitor is not loaded.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When second array reshape is about to start metadata should be updated
by mdmon in imsm_set_array_state().
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When disks are added size has to increase in metadata.
This size should be used by common code to set size in md when reshape will be finished.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For general migration function blocks_per_migr_unit() has to return valid value.
If there is no valid return, 0 is returned instead and causes division by 0 error.
Additionally guard in function was added for such case.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When reshape is finished monitor calls set_array_state() and finishes migration in metadata.
This change allows for finishing metadata migration on reshape end.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Add support for reading volume information during migration process.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
During first metadata update imsm for compatibility reason should update
only one array.
Buffers in prepare_update() are prepared for second update as well.
Signed-off-by: NeilBrown <neilb@suse.de>
Meta data was not updated due to the following problems:
1.disk index < 0 was treated as invalid, but this is spare device
2. disk index greater than currently used disks is correct also
3. newmap pointer has to be refreshed for second map copy operation
4. size calculation has to be guarded for shrinking operation
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When container operation is not allowed user has to get proper information on console about it
Currently this information was displayed as debug info only.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Correct information displayed by '-E' option.
1. FIX: Slot information during raid0 migration is displayed incorrectly
(missing disk position is taken from wrong map)
2. Improvement: information about (level, members, chunk size) migration is displayed.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Allow map related operations for the given map: first of second.
For reshape specific functionality it is required to have an access
Until now, the active map was chosen according to the current volume status.
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>
container_chose_spares in Monitor.c and
get_spares_for_grow in super-intel.c
do the same thing: search for spares in a container.
Another version will also be needed for Incremental
so a more general solution is presented here and
applied in two previous contexts.
Normally domlist==NULL would lead an empty list but
this is typically checked earlier so here it is interpreted
as "do not test domains".
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
uuid_match_any is replaced by uuid_zero for imsm spares.
Function fixup_container_spare_uuid not needed as it gives
unwanted uuid to spares.
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
We need to refuse to assemble an arrays with bad blocks.
Initially there was condition in container_content function
that returns error value in the case when metadata store information
about bad blocks.
When the container_content function is called from functions NOT connected
with assemble (Kill_subarray, Detail) we get faulty error return value.
Patch introduces new flag in array.status - MD_SB_BBM_ERRORS. It is set
in container_content when bad blocks are detected and can be checked by
container_content caller.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
delta_disks field is not always filled during getinfo_super() call.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If reshape is started resync is not allowed in parallel. This would
break reshape. If array is in General Migration state do not indicate
resync and allow for reshape continuation.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
We need to allow metadata to handle progress of reshape,
completion, and abort-before-start.
Include all those in ->set_array_state()
Signed-off-by: NeilBrown <neilb@suse.de>
Array state change is blocked due to reshape action in progress
metadata changes are during applying.
'1' is returned to indicate that array is clean
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For this update prepare_update() allocates memory to relink imsm
(bigger) device imsm structures. It calculates new /bigger/ anchor
size.
Process update applies update in to imsm structures. This includes
- converting selected spares into configured devices
- marking the arrays as migrating
- making a new 'map' for each array with the changed details.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Sometimes one metadata update will require allocating several
larger data structures. As 'monitor' cannot allocate, 'manager'
must, so it must be able to attach a list of allocates to the
update, and importantly it must be able to easily free them.
So add a 'space_list' element to metadata updates where each
element on the list starts with a pointer to the next.
Signed-off-by: NeilBrown <neilb@suse.de>
During Online Capacity Expansion metadata has to be updated to show
array changes and allow for future assembly of array. To do this
mdadm prepares and sends reshape_update metadata update to mdmon.
The update contains the old and new number of raid disks, and the
indices of the spare disks that will be used to fill the spaces.
This works as follows:
1. reshape_super() prepares metadata update.
2. mdadm discovers the spares and adds them to the array
3. mdadm sends the update to mdmon
4. managemon in prepare_update() allocates required memory for bigger
device object
5. monitor in process_update() updates the metadata to record the
new sizes and the newly assigned devices.
6. mdadm initiates the reshape
Based on code From: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For more than one disk tested additional_test_list was searched from last
point, not from begin.
This bug causes that more than 2 disks cannot be added to imsm array,
when imsm_add_spare() is used for this.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Before looking for a spare to rebuild a degraded array, check if there
are any failed disks in container. Block rebuild if another sub-array
is failed until failed disks are removed from container.
Currently, Intel metadata handler rebuilds all sub-arrays even if one
of them is non-redundant. In case of failed sub-array, failed disks
are just replaced with new ones in the metadata mapping. The data for
failed disk is not restored even the disk is present in the system.
With this fix, we require the removal of the failed disk from
container to start the process of rebuilding the array with failed
member. If the disk is physically pulled out of the system, the disk
is removed from container automatically by exiting udev rules.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Manager thread shall pass the information to monitor thread (mdmon)
that some devices are removed from container. Otherwise, monitor
(mdmon) might use such devices (spares) to rebuild the array that has
gone degraded.
This problem happens for imsm containers, since a list of the
container disks is maintained in intel_super structure. When array
goes degraded, the list is searched to find a spare disks to start
rebuild. Without this fix the rebuild could be stared on the spare
device that was a member of the container, but has been removed from
it.
New super type function handler has been introduced to prepare
metadata format specific information about removed devices.
int (*remove_from_super)(struct supertype *st, mdu_disk_info_t *dinfo)
The message prepared in remove_from_super is later processed by
process_update handler in monitor thread.
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When calling mdadm -C --metadata=imsm -l 1 /dev/sd..
mdadm segfaults in default_chunk_imsm()
above syntax is incorrect, but mdadm should error instead of segfaulting
Signed-off-by: Luca Berra <bluca@comedia.it>
Signed-off-by: NeilBrown <neilb@suse.de>
Assumption for spares searching was that after picking new device, it
has to be added to array before next search. This causes returning
different disk on each call.
When creating a spare list during Online Capacity Expansion, we will
first collect the devices list and then all devices are added to md.
Picked device from spares pool has to be checked against picked
devices so far. If not, the same disk will be returned all the time.
Already picked devices are stored in the list and this list is used
for new devices verification also.
So add an extra arg to imsm_add_spare to hold a list of known
spares to ignore.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Wrong number of disks during metadata update causes core dump. New
disks number based on internal mdmon information has to used for
calculation (not previously read from metadata).
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Internal IMSM procedures need to support the General Migration.
It is used during operations like:
- Online Capacity Expansion,
- migration initialization,
- finishing migration,
- apply changes to raid disks etc.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Support metadata specific level, layout and chunksize defaults. Kill an
uneeded superswitch methods ahead of adding more for the reshape case.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Platform (metadata) domain let the metadata handlers differentiate
disk domains based on controllers that the disk belongs to.
Platform domain is sub-domain inside user specified domain
in mdadm.conf configuration files inheriting all parameters from it.
The metadata domain name is used disk domain matching functions.
The disk with the same metadata domain name belong to the same metadata
domain.
New metadata handler is added that retrieves platform domain string based
on disk path:
const char *(*get_disk_controller_domain)(const char *path);
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If getinfo_super is called on a container supertype we only get information
on first disk. As a parameter it uses reference to preallocated
mdinfo structure. Amending getinfo_super to return full list of disks
would require ammending all previous calls and subsequently freeing memory
allocated for mdinfo list.
Function container_content that returns a mdinfo list is written
specifically for assembly, performing actions not needed to just fill
mdinfo. It also does not include spares so is unsuitable.
As an alternative a new function getinfo_super_disks is created
to obtain information about all disks states in array.
Existing function sysfs_free is used to free memory
allocated by getinfo_super_disks.
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
We are about to lose the loaded_container field, and we don't really
need to use it to protect the calculation of container_enough.
So drop the test.
Signed-off-by: NeilBrown <neilb@suse.de>
This handles the 'container' part of 'load_super', so we can
soon make them completely separate - it is just confusing to
overload these two.
Signed-off-by: NeilBrown <neilb@suse.de>
It makes more sense to test for container_dev than for subarray
for several places in Create where it then uses container_dev.
This allows us to subsequently remove subarray.
Signed-off-by: NeilBrown <neilb@suse.de>
This allows the info for a single array to be extracted,
so we don't have to write it into st->subarray.
For consistency, implement container_content for super0 and super1,
to just return the mdinfo for the single array.
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>
If an --update is requested by the relevant metadata doesn't
understand it, print a useful message rather than silently ignoring
the issue.
Signed-off-by: NeilBrown <neilb@suse.de>
If a device is less than 1K, avoid even trying to seek to 1K before
the end.
The seek will fail anyway so this is a fairly cosmetic fix.
Signed-off-by: NeilBrown <neilb@suse.de>
Labun, Marcin
Lukasz Dorau
Williams, Dan J
NeilBrown
Adam Kwolek
Przemyslaw Czarnowski
Lukasz Orlowski
Jes Sorensen
root
Thomas Jarosch
Czarnowska, Anna
Milan Broz
Luca Berra
Albert Pauw
Krzysztof Wojcik