The problem is that we need udev to create the file in /dev
for us.
It might be unnecessary for udev to consider assembling things
in this array, but it shouldn't cause a problem. If it did that
would be a different bug which we probably need locking to fix.
Or maybe udev shouldn't trigger a "-I" for containers appearing.
NeilBrown [Thu, 22 Dec 2011 22:07:14 +0000 (09:07 +1100)]
bitmap: print correct percentage of bitmap in use.
We were adding 1, presumably to avoid div-by-zero possibilities.
It is better to only substitute '1' if the value actually is zero,
else for small numbers of bits the difference is visible.
NeilBrown [Thu, 22 Dec 2011 20:42:23 +0000 (07:42 +1100)]
allow --monitor to be run by non-privileged use.
Providing --no-sharing is given, monitoring should be permitted.
Unfortunately the kernel current rejects GET_DISK_INFO and
GET_ARRAY_INFO for non-privileged users which is unjustified.
The info is available in sysfs and we could get it from there,
but for now, require the kernel to be fixed.
Adam Kwolek [Thu, 22 Dec 2011 20:13:55 +0000 (07:13 +1100)]
FIX: Verify if array name doesn't exist already
When e.g. array name (an) is correct and it is the same as container name (cn),
file element creation /dev/md/an will replace /dev/md/cn.
This can cause that user cannot access container using /dev/md/cn.
Verify during array creation if chosen name is not already existing
one.
[Changed to use map_by_name() rather than stat() to determine prior
existence - NeilBrown]
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown [Thu, 22 Dec 2011 19:59:48 +0000 (06:59 +1100)]
Grow: fix reshape-array for shrinking reshapes.
The value in info->array.raid_disks is the total number of
devices, which is the 'after' number when the number is increasing,
and the 'before' number when the number is decreasing.
The code currently assumes it is always the 'after' number - so fix
that.
NeilBrown [Thu, 22 Dec 2011 19:59:45 +0000 (06:59 +1100)]
Grow: fix start_reshape for shrinking arrays.
When an array is being reshaped to fewer data devices the relationship
between sync_max and reshape_progress is different to when the number
of devices increases - we need to allow for that when setting
sync_max/sync_min.
NeilBrown [Thu, 22 Dec 2011 19:41:52 +0000 (06:41 +1100)]
tests/03r5assemV1 - slow down recovery a bit more.
In this test we stop and restart an array that is being recovered,
and we do that several times. Sometimes it completes the recovery
before we expect and test results are wrong.
Lukasz Dorau [Fri, 16 Dec 2011 13:04:53 +0000 (14:04 +0100)]
imsm: make messages more understandable
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>
Williams, Dan J [Thu, 15 Dec 2011 02:21:07 +0000 (18:21 -0800)]
imsm: FIX: UT '08imsm-overlap' fails
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>
NeilBrown [Mon, 19 Dec 2011 23:30:34 +0000 (10:30 +1100)]
Remove update_private
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>
Adam Kwolek [Thu, 15 Dec 2011 03:35:00 +0000 (14:35 +1100)]
imsm: FIX: Chunk size migration is not possible
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>
Adam Kwolek [Thu, 15 Dec 2011 03:34:51 +0000 (14:34 +1100)]
imsm: FIX: return correct status from load_imsm_migr_rec()
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>
Adam Kwolek [Thu, 15 Dec 2011 03:34:46 +0000 (14:34 +1100)]
FIX: Add error message in container_reshape()
Add proper error message for container reshape when device cannot be opened.
fd variable operation is moved down to display information what particular
device cannot be opened.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
Adam Kwolek [Thu, 15 Dec 2011 03:34:36 +0000 (14:34 +1100)]
FIX: Do not allow for multiple reshape_array() execution during reshape_container() call
It can happen during reshape restart that reshape_array() can exit without
error (e.g. Grow.c:1915) and reshape is not moved to next array.
reshape_array() is called again for the same device.
Do not allow for such execution and check if last reshaped array is not
the current one.
This patch can be treat not as solution, but it allows for such errors
detection.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
Adam Kwolek [Mon, 12 Dec 2011 11:07:53 +0000 (12:07 +0100)]
imsm: FIX: Use first map only in migration record disk operations
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>
Adam Kwolek [Mon, 12 Dec 2011 11:07:45 +0000 (12:07 +0100)]
imsm: FIX: Limit migration record operation by disk slot not by index
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>
Adam Kwolek [Wed, 7 Dec 2011 12:58:46 +0000 (13:58 +0100)]
imsm: FIX: Use defines for device map access
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>
Adam Kwolek [Wed, 7 Dec 2011 12:57:59 +0000 (13:57 +0100)]
imsm: Function imsm_set_disk() rework
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>
Adam Kwolek [Wed, 7 Dec 2011 12:57:51 +0000 (13:57 +0100)]
imsm: FIX: Correct ords merging in end_migration()
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>
NeilBrown [Tue, 6 Dec 2011 21:39:39 +0000 (08:39 +1100)]
monitor: don't unblock a device that isn't blocked.
When we see a failed device, we both unblock and remove it (after
updating the metadata).
However it might not be blocked as there can be a delay between
unblocking and the device being free to be removed.
If this happens the clearing of 'blocked' succeeds so md sends a sysfs
notification and mdmon checks again and tries to clear 'blocked'
again.
Thus it enters a busy-loop until the 'remove' succeeds.
To avoid this, only try to unblock if the device was blocked.
Adam Kwolek [Tue, 6 Dec 2011 00:44:07 +0000 (11:44 +1100)]
imsm: FIX: Just created redundant array is not in uninitialized state
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>
imsm: fix: does not allow to use invalid chunk size
Only least significant bit of chunk size provided by user has been used
in test with OROM capabilities. This way user could pass value which is
not a power of 2.
Adam Kwolek [Tue, 6 Dec 2011 00:37:16 +0000 (11:37 +1100)]
imsm: FIX: Function rework - imsm_count_failed()
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>
Adam Kwolek [Tue, 6 Dec 2011 00:30:16 +0000 (11:30 +1100)]
imsm: FIX: Restore critical section on degraded array
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>
Adam Kwolek [Tue, 6 Dec 2011 00:28:04 +0000 (11:28 +1100)]
imsm: FIX: Remove single map state limitation in getinfo
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>
Adam Kwolek [Tue, 6 Dec 2011 00:24:22 +0000 (11:24 +1100)]
imsm: FIX: Do not end migration when missing drive is handled
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>
Adam Kwolek [Tue, 6 Dec 2011 00:21:23 +0000 (11:21 +1100)]
imsm: FIX: Mark both maps on degradation while migrating
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>
Adam Kwolek [Tue, 6 Dec 2011 00:17:26 +0000 (11:17 +1100)]
imsm: FIX: Return longer map for failure setting
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>
Lukasz Dorau [Fri, 18 Nov 2011 14:34:33 +0000 (15:34 +0100)]
fix: correct metadata's update communication
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.
Lukasz Dorau [Fri, 18 Nov 2011 14:28:36 +0000 (15:28 +0100)]
imsm: fix: correct printing value of blocks per migration unit
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.
Labun, Marcin [Wed, 16 Nov 2011 04:24:10 +0000 (15:24 +1100)]
imsm: platform capabilities are not validated during level migration
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>
Lukasz Dorau [Mon, 14 Nov 2011 14:52:52 +0000 (15:52 +0100)]
imsm: fix: correct checking newly missing disks
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.
Lukasz Orlowski [Mon, 14 Nov 2011 05:41:03 +0000 (16:41 +1100)]
imsm: fix: Allowed to create 2 volumes with total size less then maximum.
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.
Lukasz Dorau [Mon, 7 Nov 2011 01:23:49 +0000 (12:23 +1100)]
imsm: fix: add support for OLCE and migration to imsm_count_failed
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.
Lukasz Orlowski [Mon, 7 Nov 2011 01:20:34 +0000 (12:20 +1100)]
fix: Allowed to assemble 2 volumes with the same names from config file.
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.
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 819c158866f466075a1c719f0dc496deb2fb3814
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>
NeilBrown [Tue, 1 Nov 2011 04:45:46 +0000 (15:45 +1100)]
Grow: fix check_reshape and open_code it.
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.