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>
NeilBrown [Mon, 1 Aug 2011 02:21:19 +0000 (12:21 +1000)]
Add some more settings of ignore_hw_compat
There are some more times when we don't care that the hardware doesn't
support the metadata:
- when removing old metadata
- when reporting the metadata present before over-writing it.
- explain it's use in guarding against small replacements
- clarify relationship with containers.
- include information about --grow --size not being supported by IMSM metadata.
imsm: getinfo_super_imsm_volume() doesn't fill all disk information
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.
Milan Broz [Thu, 14 Jul 2011 03:58:36 +0000 (13:58 +1000)]
mdadm: fix build failures (ppc64)
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>
Krzysztof Wojcik [Thu, 23 Jun 2011 02:06:47 +0000 (12:06 +1000)]
Show DELAYED, PENDING status of resync process in "--detail"
Initially there is no proper translation mdstat's DELAYED/PENDING processes
to "--detail" output.
For example, if we have recover=DELAYED in mdstat, "--detail"
shows "State: recovering" and "Rebuild Status = 0%".
It was incorrect in case of process waiting on checkpoint different
than 0%. In fact rebuild status is differnt than 0% and user is misled.
The patch fix the problem. Current "--detail" command shows
in the exampe: "State: recovering (DELAYED)" and no information
about precentage.
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
Namhyung Kim [Tue, 21 Jun 2011 16:19:03 +0000 (01:19 +0900)]
mdadm.8: move description of --add under Grow mode
It is supposed to be under Grow mode. Since Create/Build/Grow modes
use common options and '-a' is already used for '--auto' in Create/
Build modes, describe it to avoid confusion.
Luca Berra [Fri, 17 Jun 2011 04:41:01 +0000 (14:41 +1000)]
Improvements to GPT reading code.
looking at the gpt code in util.c i found i did not like it at all, a
gpt partition entry is currently 128 bytes, but the spec does not say it
is a fixed value, so the code that reads into a buffer with 512bytes
chunk expecting this to be a multiplier of part_size is imho incorrect.
my fix was to read each partition entry directly into a struct
GPT_part_entry, the advantage is that the code is very simple to read,
the disadvantage it is 128 reads of 128 bytes each, which is
sub-optimal, but i believe readahead will mitigate this a lot.
Adam Kwolek [Tue, 14 Jun 2011 13:59:18 +0000 (15:59 +0200)]
imsm: Metadata Attributes compatibility support
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>
Adam Kwolek [Tue, 14 Jun 2011 23:13:49 +0000 (09:13 +1000)]
imsm: FIX: Sometimes reshape cannot be finished
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>
Adam Kwolek [Tue, 14 Jun 2011 02:46:53 +0000 (12:46 +1000)]
imsm: FIX: Migration Raid0->Raid5 cannot be restarted correctly
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>
Adam Kwolek [Tue, 14 Jun 2011 02:42:22 +0000 (12:42 +1000)]
imsm: FIX: Raid5 data corruption data recovering from backup
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>
Adam Kwolek [Tue, 14 Jun 2011 02:42:16 +0000 (12:42 +1000)]
imsm: FIX: Disable automatic metadata rollback for broken reshape
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>
projects / thirdparty / mdadm.git / log
