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>
Reshape backup should be able to be restored during reshape continuation
also. To reuse already existing code it is moved to function.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For fdlist pointer allocated in assemble_container_content() function,
free() is never called. This patch fixes this memory leak.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
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>
This set the metadata to 1.2, not 1.0.
When the default was changed to 1.2 I forgot to update this part of
the man page.
Bug-Debian: http://bugs.debian.org/607375
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).
Signed-off-by: Lukasz Dorau <lukasz.dorau@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>
Few things adjusted in addition to
0f82fe603a42f37f1e2a6f826b4164811bf2d188:
- keep strict tests for supported types
- when accessing the device, use $tempnode
- few more comments
Signed-off-by: Michal Soltys <soltys@ziu.info>
Signed-off-by: NeilBrown <neilb@suse.de>
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.
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Moving spares is not the purpose of '--oneshot' and without
currently --oneshot doesn't work as the check against multiple
spare-sharers prevents it.
So make --oneshot imply --no-sharing. This is sensible and allows
--oneshot to work again.
Reported-by: Jamie Heilman <jamie@audible.transient.net>
Resolves-Debian-Bug: 641886
Signed-off-by: NeilBrown <neilb@suse.de>
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.
Signed-off-by: NeilBrown <neilb@suse.de>
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.
Signed-off-by: NeilBrown <neilb@suse.de>
A 0.90 array can use at most 4TB of each device - 2TB between
2.6.39 and 3.1 due to a kernel bug.
The test for this in validate_super0 is very wrong. 'size' is sectors
and the number it is compared against is just confusing.
So fix it all up and correct the spelling of terabytes and remove
a second redundant test on 'size'.
Signed-off-by: NeilBrown <neilb@suse.de>
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>
This implicitly adds ddf containers to 'add' and 'remove' rules.
Signed-off-by: Michal Soltys <soltys@ziu.info>
Signed-off-by: NeilBrown <neilb@suse.de>
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.
Signed-off-by: NeilBrown <neilb@suse.de>
When not all attributes are supported (attributes incompatibility)
function container_content_imsm returns NULL pointer.
We need to cope with a NULL list better.
Reported-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
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.
Signed-off-by: Lukasz Dorau <lukasz.dorau@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>
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.
#!/bin/bash
i=0
false
while [ $? == 1 ]
do
i=$((i+1))
mdadm -Ss
mdadm -CR /dev/md0 /dev/loop[0-2] -n 3 -e imsm
mdadm -CR /dev/md1 /dev/loop[01] missing -n 3 -l 5
mdadm --wait /dev/md1
mdadm -E /dev/loop2 | grep -i degraded
done
echo "failed: $i"
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>
Not sure how this ever worked, but now we just try to parse a directory
name that looks like <host>:<bus>:<target>:<lun>.
Array creation segfaults on Fedora 14 without this.
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>
Update to latest from http://www.gnu.org/licenses/gpl-2.0.txt
This corrects the address and some other minor details.
No change in the license.
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>
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.
So set ignore_hw_compat in these cases.
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>
- explain it's use in guarding against small replacements
- clarify relationship with containers.
- include information about --grow --size not being supported by IMSM metadata.
Reported-by: maciej.naruszewicz <maciej.naruszewicz@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
As the conditional checks, reshape to fewer devices is supported
since Linux kernel 2.6.30 not 2.6.32.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
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>
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>
Since info->delta_disks is signed it doesn't need to be special-cased.
This allowed my 9->8 reshape to display correctly instead of as 8->7
Signed-off-by: NeilBrown <neilb@suse.de>
Fix random typos and add a few of missing words/macros.
Also update RAID website URL as it is not accessible anymore.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown
Lukasz Orlowski
Adam Kwolek
Lukasz Dorau
Michal Soltys
Doug Ledford
Thomas Jarosch
Czarnowska, Anna
Dan Williams
Bill Allaire
Piergiorgio Sartor
Scott Schaefer
Namhyung Kim
Milan Broz
Krzysztof Wojcik
Andrew Burgess