If mdmon sees a device added to a container, it should assume it is
a new spare. It could be a part of the array that just hadn't been
assembled yet. So check first.
Signed-off-by: NeilBrown <neilb@suse.de>
If we haven't got hold of all the devices yet, we need to be
ready to skip over some while gathering content information.
Signed-off-by: NeilBrown <neilb@suse.de>
If we are assembling an array in a container and it isn't complete
enough to start yet, then
- don't start mdmon
- don't say the array is started
- don't wait for the device to appear in /dev
Signed-off-by: NeilBrown <neilb@suse.de>
If we need to add digits to a name to make it unique, but don't have
to add '_', we need to avoid adding a digit immediately after a digit.
So if the last character of the name is a digit, add the '_' anyway.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ if homehost matches, then we need to set trustworthy to 'LOCAL'
2/ if we decide to set trustworthy to 'METADATA' because we have to
use the metadata version name, do that *after* we have checked if
we are going to assemble within a container, as inside the
container there could be different sources of names to use.
Signed-off-by: NeilBrown <neilb@suse.de>
DDF raid6 layouts are subtly different from the standard 'md' layouts.
From 2.6.30 the kernel knows about these.
Teach mdadm about them, and also allow 'ddf' to set an appropriate default.
Signed-off-by: NeilBrown <neilb@suse.de>
The information about how slots and roles in the array lined up
turned out to be confusing.
So simplify it and one provide the interesting information.
Signed-off-by: NeilBrown <neilb@suse.de>
If the sector size is > 512, we need to be more careful about
alignment.
The largest known sector size is 4096 and (fortunately) both the
superblock and (in many cases) the bitmap are 4096-byte aligned.
So there should be no data-overlap problems.
The exception is when the bitmap is squeezed into the 3K after the
superblock. This arrangement cannot currently be supported on
4K sector-size devices.
Signed-off-by: NeilBrown <neilb@suse.de>
.. because some devices (dasd) have 4096 byte sector size.
As the superblock is 4096 bytes and the bitmap is in a
60K region, this is safe from any possible corruption.
Signed-off-by: NeilBrown <neilb@suse.de>
There was a few kernel releases where the kernel would shrink max_dev
to be just enough to hold the current number of devices.
More recent kernels never shrink it.
However to be as compatible as possible, if we notice that
max_dev is too small to successfully add a device, increase it.
Signed-off-by: NeilBrown <neilb@suse.de>
Currently Incremental_container is being called after adding each disk.
In the imsm case where spares are not tracked in the raid_disks field we
can use --no-degraded to block premature assembly.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Just like the Assemble case, default to the text_version of the
container if another name is not specified.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
mdmon may miss events because it re-reads state after read_and_act. The
additional read is used to determine dirty status before allowing a
sigterm to proceed. Since read_and_act is in the best position to
determine 'dirty' status and its return value is not used, modify it to
return true if the array is dirty.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
In support of auto-layout:
1/ collect and merge all extents to find the largest common-start free region
2/ verify that we meet the "all volumes must use the same set of disks"
2/ mark the disks to be added in add_to_super_imsm_volume
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
'subdevs' is read from the container in the auto-layout case so reset
subdevs dependent default values. 'insert_point' without this
change is always 2 blocking creation of arrays with > 2 raid disks.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Skip the unique holder check in the detached case... pretty sure no one is
holding on to it if open() returns ENXIO.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
All operations that rely on loading from an existing container (like
--add) will fail after a disk has been removed. Provide an option to
skip missing / offline disks rather than abort. We attempt to do this
in the load_super_{imsm,ddf}_all cases when mdmon is running i.e. we
already have a consitent version of the metadata running in the system.
Otherwise, we fail as normal and let the administrator fix up the
container.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If the checksum verification fails and mdmon is running we retry the
load to get a consistent snapshot of the mpb. Found by
tests/08imsm-overlap.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Actually, rename mark_failure to mark_missing and then implement the
correct mark_failure which according to new documentation is to:
1/ Set the FAILED status bit
2/ Set IMSM_ORD_REBUILD to mark the disk out of sync
3/ Set map->failed_disk_num if this is the first failure detected
failure (it is ~0 otherwise)
Previously the assumption was that IMSM_ORD_REBUILD only appeared in
map[1], so all routines that care about out-of-sync disks need to be
updated.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
A foreign disk is one that all other drives believe is not-in-sync but
does not have the 'failed' status bit set.
This also reverts, because that commit is addressing the wrong problem.
Ideally mdmon would kick "non-fresh" drives like the kernel does at
native-md activation time, but that is too awkward to implement at the
moment because mdadm owns container manipulations.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Spares in the imsm case are marked with the "match-all" uuid of
ffffffff-ffffffff-ffffffff-ffffffff. When performing incremental
assembly we need to associate such devices with a populated container
uuid. Also when performing --detail on a container with only spares
present we can make an attempt to return a real uuid.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
IMSM_NO_PLATFORM turns off checks that should be tested, so provide a
IMSM_TEST_OROM variable to allow testing the orom constraints in the
mdadm regression suite.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
"mdadm --monitor --test --scan" currently only sends test messages for
arrays listed on the command line or in /etc/mdadm.conf. With this
patch it also reports on any active arrays, which is more in line with
the description in the manpage.
Thanks to Andrew Walrond <andrew@walrond.org> for reporting this error.
Signed-off-by: NeilBrown <neilb@suse.de>
mdadm -C /dev/md/r1d2n1s0-5 -amd -l1 --size 5242880 -n 2 /dev/sdb /dev/sdc -R -f -v -c 64
mdadm: chunk size ignored for this level
mdadm: super0.90 cannot open /dev/sdb: Device or resource busy
mdadm: super1.x cannot open /dev/sdb: Device or resource busy
mdadm: platform does not support a chunk size of: 0
mdadm: device /dev/sdb not suitable for any style of array
Reported-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Tested-by: Jacek Danecki <jacek.danecki@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
We really should never divide by 0.
Thanks to "Jon Nelson" <jnelson-linux-raid@jamponi.net>
for finding the problem.
Signed-off-by: NeilBrown <neilb@suse.de>
As get_component_size() returns the number of used sectors of a device
we need halve before pringing as K, and shift the value by 9, not 10,
before passing to human_size.
Thanks to Andre Noll <maan@systemlinux.org> for identifying problem
(and a slightly different version of this patch)
Signed-off-by: NeilBrown <neilb@suse.de>
2008-12-08 Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
* Makefile (dadm.uclibc): Remove misspelled and unneeded rule.
* md5.h: Include stdint.h for uClibc.
* mdadm.h: uClibc defines __UCLIBC__. If uClibc has LFS off
then use lseek instead of lseek64.
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>