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.
NeilBrown [Tue, 1 Nov 2011 02:30:44 +0000 (13:30 +1100)]
Kill: remove duplicate tests on 'force'.
We test 'force' twice with the second having not chance of
taking effect.
As a result a subsequent message - intended for use in the 'force'
case is never generated.
Labun, Marcin [Mon, 31 Oct 2011 00:29:46 +0000 (11:29 +1100)]
kill-subarray: fix, IMSM cannot kill-subarray with unsupported metadata
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>
Jes Sorensen [Sun, 30 Oct 2011 23:24:55 +0000 (10:24 +1100)]
Avoid stack overflow if GPT partition entries on disk are > 128 bytes
Per [1] GPT partition table entries are not guaranteed to be 128
bytes, in which case read() straight into a struct GPT_part_entry
would result in a buffer overflow corrupting the stack.
Adam Kwolek [Wed, 26 Oct 2011 16:16:55 +0000 (18:16 +0200)]
FIX: Close unused handle in child process during reshape restart
When array reshape (e.g. raid0->raid5 migration) is restarted during
array assembly, file system placed on this array cannot be mounted until
reshape is finished due to "busy" error.
This is caused when reshape is executed on array for external metadata
and array handle is cloned /forked/ to child process environment but not
closed.
Handle can't be closed before executing Grow_continue() because it is
used later in code.
Close unused handle in child process /reshape_container()/.
It is similar to close fd handle in reshape_array() before calling
manage_reshape()/child_monitor() in Grow.c:2290.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
root [Sat, 22 Oct 2011 00:42:16 +0000 (11:42 +1100)]
imsm: fix: Fixes metadata after migration from Raid 0 to Raid 10
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.
Jes Sorensen [Sat, 22 Oct 2011 00:29:47 +0000 (11:29 +1100)]
Remove race for starting container devices.
This moves the lock handling out of Incremental_container() and relies
on the caller holding the lock. This prevents conflict with a
follow-on mdadm comment which may try and launch the device in
parallel.
This involves replacing a call to "Incremental" with an
unrolled version with just the case that calls Incremental_container
and so needs a call to ->load_container.
Lukasz Dorau [Wed, 19 Oct 2011 13:16:33 +0000 (15:16 +0200)]
imsm: fix: correct debug printing of the volume's name
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.
Lukasz Dorau [Wed, 19 Oct 2011 09:51:48 +0000 (11:51 +0200)]
imsm: fix: prevent segfault in mark_failure
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.
Adam Kwolek [Thu, 6 Oct 2011 09:13:22 +0000 (11:13 +0200)]
Always run Grow_continue() for started array.
So far there were 2 reshape continuation cases:
1. array is started /e.g. reshape was already invoked during initrd
start-up stage using "--freeze-reshape" option/
2. array is not started yet /"normal" assembling array under reshape case/
This patch narrows continuation cases in to single one. To do this
array should be started /set readonly in to array_state/ before calling
Grow_continue() function.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
imsm: always use set_migr_type to set type of migration
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.
NeilBrown [Thu, 6 Oct 2011 02:00:28 +0000 (13:00 +1100)]
Fix handling for "auto" line in mdadm.conf
Two problems.
1/ pol_merge was ignoring the pol_auto tag so any 'auto' information
was lost
2/ If a device had not path (e.g. loop devices) or if there were no
path-based policies, we didn't bother looking for policy at all.
So path-independant policies were ignored.
Reported-by: Christian Boltz <suse-beta@cboltz.de> Signed-off-by: NeilBrown <neilb@suse.de>
Lukasz Dorau [Wed, 5 Oct 2011 03:17:38 +0000 (14:17 +1100)]
imsm: fix: correct adding and activation of spare disks
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().
Adam Kwolek [Wed, 5 Oct 2011 03:00:00 +0000 (14:00 +1100)]
Set correct reshape restart position
This patch version is simplified compared to previous one.
There is no use of freeze_reshape flag in start_reshape(). It is assumed
that for reshape starting condition reshape_progress field contains
0 value /correct start position/. For reshape restart case, it contains
correct restart position. This approach doesn't make start_reshape()
difficult to read/manage and /imho/ kernel changes to change mdstat
reporting behavior are not necessary.
Setting correct position allows user to see it in the mdstat during
reshape restart and reshape process is not reported as resync.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
Adam Kwolek [Wed, 5 Oct 2011 02:59:28 +0000 (13:59 +1100)]
Monitor reshaped array
Reshape can be run for monitored arrays only /external metadata case/.
Before reshape can be executed, make sure that just starter array/container
is monitored. If not, run mdmon for it.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
Adam Kwolek [Wed, 5 Oct 2011 02:33:29 +0000 (13:33 +1100)]
Remove freeze() call from Grow_continue()
Grow_continue() for external metadata should be executed on blocked
from monitoring array(s)/container.
Additional call to freeze() is not necessary in such case.
It produces meaningless error message only.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
Adam Kwolek [Wed, 5 Oct 2011 02:30:50 +0000 (13:30 +1100)]
Add recovery blocked field to mdinfo
When container is assembled while reshape is active on one of its member
whole container can be required to be blocked from monitoring.
For such purpose field recovery blocked is added to mdinfo structure.
When metadata handler finds active reshape in container it should set
recovery_blocked field to disable whole container monitoring during
reshape.
For arrays that doesn't use containers, recovery_blocked field
has the same value as reshape_active field e.g. super0/1.
In fact,recovery is blocked during reshape for such arrays.
For ddf, metadata handler doesn't set reshape_active field,
so recovery_blocked is not set also.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
Adam Kwolek [Sun, 2 Oct 2011 23:31:22 +0000 (10:31 +1100)]
imsm: Do not mark resync during reshape
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>
Adam Kwolek [Sun, 2 Oct 2011 23:30:28 +0000 (10:30 +1100)]
imsm: FIX: Do not allow for spare disk activation during reshape
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>
Adam Kwolek [Sun, 2 Oct 2011 23:09:21 +0000 (10:09 +1100)]
Manual update for --continue option
Patch adds to mdadm man the following information:
--continue
This option is complementary pair to assembly --freeze-reshape option.
It is needed when --grow operation is interrupted and it is not restarted
automatically due to --freeze-reshape usage during array assembly.
Option --continue has to be used together with -G , ( --grow ) command
and device that it should be executed on. All parameters required for
reshape continuation will be read from array metadata. If initial
--grow command had required --backup-file= option to be set,
continuation option will require to have exactly the same backup
file pointed to also.
Any other parameter passed together with --continue option will be ignored.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
Adam Kwolek [Sun, 2 Oct 2011 23:07:30 +0000 (10:07 +1100)]
Manual update for --continue option
Patch adds to mdadm man the following information:
--freeze-reshape
Option is intended to be used in start-up scripts during initrd boot
phase. When array under reshape is assembled during initrd phase,
this option stops reshape after reshape critical section is being
restored. This happens before file system pivot operation and avoids lost
of file system context. Loosing file system context would cause
reshape to be broken.
Reshape can be continued later using -continue option for grow command.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
Adam Kwolek [Sun, 2 Oct 2011 22:26:48 +0000 (09:26 +1100)]
Add continue option to grow command
To allow for reshape continuation '--continue' option is added
to grow command.
Function that will be executed in grow-continue case doesn't require
information about reshape geometry. All required information are read
from metadata.
For external metadata reshape can be run for monitored array/container
only. In case when array/container is not monitored run mdmon for it.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
Adam Kwolek [Sun, 2 Oct 2011 22:15:22 +0000 (09:15 +1100)]
Do not continue reshape during initrd phase
During initrd phase continuing reshape will cause file system context
lost. This blocks ability to control reshape using checkpoints.
To avoid this, during initrd phase assemble has to be executed with
'--freeze-reshape' option. This causes that mdadm restores reshape
critical section only.
Reshape can be continued later after system full boot.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
Czarnowska, Anna [Mon, 19 Sep 2011 12:57:48 +0000 (12:57 +0000)]
imsm: Calculate reservation for a spare based on active disks in container
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.
projects / thirdparty / mdadm.git / log
