Not all kernels automatically discard partitions when the
array is stopped, so call the RRPART ioctl to force it.
Signed-off-by: NeilBrown <neilb@suse.de>
It is possible for the mapfile to become wrong, and that gets
very confusing. So validate entries before returning them.
Signed-off-by: NeilBrown <neilb@suse.de>
If udev hasn't created the array yet, we might still want to
open it. So open directly by major:minor.
Also, of array in map file doesn't appear to exist, do use
the name associated with it.
Signed-off-by: NeilBrown <neilb@suse.de>
So if the array with minor number matching the name of a new array
already exists, just assemble with a different minor number.
Signed-off-by: NeilBrown <neilb@suse.de>
As we open and close so quickly, udev might still have the device
open. so call udevsettle before stopping an array during testing.
Signed-off-by: NeilBrown <neilb@suse.de>
When we create our own ddf array, store the homehost in the vendor
information so it can be so to ensure 'LOCAL' name choices.
Signed-off-by: NeilBrown <neilb@suse.de>
As with Assemble, one create_mddev has chosen a name, we should always
use that rather than the passed 'mddev'.
Signed-off-by: NeilBrown <neilb@suse.de>
As spares are treated quite differently in containers, we cannot
fake-up a spare to optimise initialisation for a raid5 in a container,
so disable that code for ->external arrays.
Signed-off-by: NeilBrown <neilb@suse.de>
Rather than appending the md minor number, we now append a small
sequence number to make sure name in /dev/md/ that aren't LOCAL are
unique. As the map file is locked while we do this, we are sure
of no losing any races.
Signed-off-by: NeilBrown <neilb@suse.de>
We probably should pass a flag down saying 'this is auto-assembly',
but for now, if there is no identity information set, it must
be auto-assemble.
Signed-off-by: NeilBrown <neilb@suse.de>
Try to treat members of containers much like other arrays for
assembly.
We still look through the list of devices for a match (it will be
the container), then find the relevant 'info' and try to assemble
the array.
Signed-off-by: NeilBrown <neilb@suse.de>
Attempting to open(O_EXCL) each candidate device usually filters out all
busy raid components. However, containers do not behave like components
and will return container_content that may describe active member
arrays.
This patch just adds a function that will be used to check if a
container member is busy. It will be used shortly.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Factor out, from Incremental_container, the code for assembling an
array based on information extracted from a container. We will
shortly use this from Assemble too.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
In preparation for handling the container case where we may need to handle
a list of potential member arrays.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Add anything that looks like a container in /proc/mdstat to the devlist
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If there is no metadata (--build was used) then we need to lookup
by devnum, not by uuid, to get the map entry.
Signed-off-by: NeilBrown <neilb@suse.de>
This only applies if udev isn't installed or is disabled
by MDADM_NO_UDEV
We try to remove partitions too.
We find names to remove by looking in /var/run/mdadm/map
Signed-off-by: NeilBrown <neilb@suse.de>
When a 'container' gets started, we need udev to notice, but the
kernel has no way of knowing that a KOBJ_CHANGE event is needed. So
send one directly via the 'uevent' sysfs attribute.
Also, uevents don't get generated when md arrays are stopped (prior to
2.6.28) so send 'change' events then too.
Signed-off-by: NeilBrown <neilb@suse.de>
MD_NAME is the name of the array extracted directly from the metadata.
MD_DEVNAME is the current working name of the array. It should appear
in /dev/md. It is possibly what the user gave when creating the
array.
We extract it from /var/run/mdadm/map.
Signed-off-by: NeilBrown <neilb@suse.de>
We previously only updated /var/run/mdadm/map when starting an
array with --incremental. However we now make more use of
that file (to pass the dev name to udev) so always update it.
Signed-off-by: NeilBrown <neilb@suse.de>
When mdadm.conf is automatically generated, we might not know a
suitable /dev/name. But we do know the uuid of the container.
So allow that as an option.
Signed-off-by: NeilBrown <neilb@suse.de>
i.e. in mdadm.conf you can have a line like
ARRAY uuid=whatever
and it will use auto-name-generation to give a name to the array at
assemble-time. The is different from blind auto-assembly in that the
array will be treated as 'local'.
Change the "env_check_mdmon" function to be more generic, accepting
and environment variable name, as soon we will have a new use for it.
Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown
Dan Williams