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.
Adam Kwolek [Wed, 21 Sep 2011 01:55:08 +0000 (11:55 +1000)]
FIX: Do not unblock array accidentally
When sysfs_set_array() function is called, it tests if array
can be configured using sysfs. Setting metadata_version entry
can accidentally unblock mdmon when array is under reshape.
To avoid this, blocking character '-' is checked and if is is set,
it is used for array test.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
During reshape function restore_stripes is called periodically
and every time the buffer stripe_buf (of size raid_disks*chunk_size)
is allocated but is not freed. It happens also upon successful completion.
In case of huge arrays it can lead to the seizure of the entire
system memory (even of the order of gigabytes).
Adam Kwolek [Thu, 15 Sep 2011 16:38:39 +0000 (18:38 +0200)]
imsm: FIX: Spare disk has wrong serial after takeover
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>
Fix readding of a readwrite drive into a writemostly array
If you create a two drive raid1 array with one device writemostly, then
fail the readwrite drive, when you add a new device, it will get the
writemostly bit copied out of the remaining device's superblock into
it's own. You can then remove the new drive and readd it as readwrite,
which will work for the readd, but it leaves the stale WriteMostly1 bit
in devflags resulting in the device going back to writemostly on the
next assembly.
The fix is to make sure that A) when we readd a device and we might have
filled the st->sb info from a running device instead of the device being
readded, then clear/set the WriteMostly1 bit in the super1 struct in
addition to setting the disk state (ditto for super0, but slightly
different mechanism) and B) when adding a clean device to an array (when
we most certainly did copy the superblock info from an existing device),
then clear any writemostly bits.
A kernel bug makes handling for arrays using more than 2TB per device
incorrect, and the kernel doesn't stop an array from growing beyond
any limit.
This is fixed in 3.1
So prior to 3.1, make sure not to ask for an array to grow bigger than
2TB per device.
Discourage large devices from being added to 0.90 arrays.
0.90 arrays can only use up to 4TB per device. So when a larger
device is added, complain a bit. Still allow it if --force is given
as there could be a valid use.
fix: segfault when killing subarray of non-existent container
Negative value must be returned to indicate error in open_subarray
Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
start_mdmon: provide more dynamic way to close-all-fds
When forking mdmon we need to close all other fds because we don't
use O_CLOEXEC yet.
Any approach will be fairly arbitrary, but as we can expect fds to be
fairly dense, closing until we find a set number that don't need
closing is possible safer than only closing the first 100.
So keep closing until we find 20 that are already closed.
When not all attributes are supported (attributes incompatibility)
function container_content_imsm returns NULL pointer.
We need to cope with a NULL list better.
FIX: Mdmon crashes after changing RAID level from 1 to 0
Description of the bug:
Sometimes mdmon crashes after changing RAID level from 1 to 0 (takeover).
Cause of the bug:
The managemon marks an active_array for removal from monitoring
by assigning a->container to NULL value (in the "manage_member" function).
Sometimes (during stress test) it happens right when the monitor
is in the "read_and_act" function and a->container pointer is in use.
This causes the monitor crashes.
Solution:
The active array has to be marked for removal in another way
than setting NULL pointer when it can be in use.
A new field "to_remove" was added to the "active_array" structure.
It is used in the managemon to mark a container to remove
(instead of the old assigment: a->container = NULL)
and monitor checks it to determine if the array should be removed.
The field "to_remove" should be checked in some other places
to avoid managing of the array which is going to be removed.
Dan Williams [Tue, 30 Aug 2011 03:11:42 +0000 (13:11 +1000)]
imsm: support 'missing' devices at Create
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>
Dan Williams [Fri, 26 Aug 2011 02:14:29 +0000 (19:14 -0700)]
mdmon: fix, close spare activation race
The following test fails when the md_check_recovery() event triggered by
the ro->rw transition causes remove_and_add_spares() to run while mdmon
is attempting spare activation.
Result is that the kernel races to set the slot immediately after
sysfs_add_disk() writes new_dev. mdmon thinks the spare activation
failed and declines to send the monitor a new acitve_array. We show
degraded after the wait because the monitor cannot notify the metadata
that all disks are in_sync.
Dan Williams [Fri, 26 Aug 2011 02:14:24 +0000 (19:14 -0700)]
imsm: fix reserved sectors for spares
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>
Dan Williams [Fri, 26 Aug 2011 02:14:14 +0000 (19:14 -0700)]
imsm: fix display spares
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>
Dan Williams [Fri, 26 Aug 2011 02:14:09 +0000 (19:14 -0700)]
imsm: fix, stop metadata updates to newly failed devices
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>
Dan Williams [Fri, 26 Aug 2011 02:14:04 +0000 (19:14 -0700)]
imsm: fix max disks per array
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>