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>
Failed disks do not have valid serial numbers which means we will not
pick up the 'failed' status bit from the metadata entry. Check for
dl->index == -2 to prevent failed disks from being incorporated into the
container.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If the metadata handler can not find its platform support components
then there is no way for it to verify that the raid configuration will
be supported by the option-rom. Provide a generic method for metadata
handlers to warn the user that the array they are about to create may
not work as intended with a given platform.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
This is a key orom-compatibility constraint. A nice side effect is that
it precludes the corner case of 'create' racing against 'spare activate'
since the create will fail to convert a spare into an array member. At
create time we check if this is the first member array in the container
if it is than all disks are possible candidates, if it is not then only
current members are permitted.
A bit hairier is spare-activation handling in the presence of this
constraint. It is difficult because spare handling is per array. The
approach taken is to:
1/ check that a new spare can cover all defined arrays in the container
2/ ensure that partially assimilated spares are the first candidates
when looking for a spare region to activate.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Let handlers specifiy their own defaults, specifically needed for the
imsm-raid5 case where mdadm defaults to 'ls' and imsm to 'la'.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Use mddev_busy() as GET_ARRAY_INFO can succeed on 'clear' arrays.
Ran into this after an encountering a case where mdadm -Ss ended in
segfault (missing check for NULL return from map_by_devnum() in
sles11:Manage.c). So, tried to stop the array by hand with echo clear >
md/array_state, after which I could not reassemble since GET_ARRAY_INFO
was succeeding.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
When the given container is '/proc/mdstat' then launch an mdmon instance
per container found in /proc/mdstat.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Allow any path that dereferences to an md device to be used in addition
to the current symbolic md device names.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
It is possible for some arrays to be created e.g. by initrd, and so
not get mentioned in /var/run/mdadm/map.
As "-I" depends on things being listed in 'map', we create it by
scanning all devices if it doesn't exist.
Signed-off-by: NeilBrown <neilb@suse.de>
Reshape with large chunk size can require a large stripe_cache.
We make this work when starting the reshape but not when
restarting at assemble time. So fix that.
Signed-off-by: NeilBrown <neilb@suse.de>
This is only significant for --assemble --force where some old
devices might be included into the array. If anything looks like
it isn't clean, the kernel will not allow a degraded array to be started.
Signed-off-by: NeilBrown <neilb@suse.de>
We really want --zero-super --force to zero the superblock in
all situations. So don't open with O_EXCL - trust the user.
Signed-off-by: NeilBrown <neilb@suse.de>
The 'udevadm settle' call appears to resolve:
mdadm: failed to stop array /dev/md127: Device or resource busy
Perhaps a running process, mounted filesystem or active volume group?
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Dump the orom capabilities and hardware disk configuration. This code
relies on the name of scsi_host objects to determine the hardware port
number. Hopefully this information is stable...
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Metadata formats like imsm work in concert with platform firmware and
hardware, so provide a way for mdadm to display this info to the user.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
These checks are only enabled when platform support for imsm is found,
i.e. ahci driver is loaded and talking to an Intel(R) controller, and
the option rom header is located.
They can be turned off by setting the environment variable
IMSM_NO_PLATFORM to 1.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The option-rom advertises its capabilities in a data structure located in
the platform ROM region 0xc0000-0xf0000. Attempt to detect the option-rom
and limit array creation to the platform's capabilities.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
imsm metadata requires all members of a raid volume to start at the same
offset. So, incrementally build a composite disk from all the
candidates passed to ->validate_geometry. After each disk is added
merge the extents and search for a common start offset that satisfies
the requested raid device size.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
When chunksize is 0 in the raid1 case we need to use
info_to_blocks_per_member() to calculate the array size.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If, when creating an array, a signal target device is given which
is a container, then allow the metadata handler to choose which
devices to use.
This is currently only supported for DDF.
Signed-off-by: NeilBrown <neilb@suse.de>
