We sometimes set failed_disk_num to ~0.
However we cannot test for equality with that as failed_disk_num
is 8bit and ~0 is probably 32bit with lots of 1's.
So test if ~failed_disk_num is 0 instead.
Reported-By: "Mr. James W. Laferriere" <babydr@baby-dragons.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Since 2.6.16, mdstat responds to select/poll.
So in that case, increase the default poll interval to about 15
minutes.
This ensures that the background load is insignificant.
Signed-off-by: NeilBrown <neilb@suse.de>
externally managed arrays do not (currently) cause utime in
GET_ARRAY_INFO to be updated. So if it is zero, just assume the
current time.
This will cause GET_DISK_INFO to be called more often, but as we do
the scan only every 60 seconds normally, a few extra syscalls isn't
going to make a big difference.
Signed-off-by: NeilBrown <neilb@suse.de>
The auto parameter is obsolete after kernel version 2.6.28 as all arrays
are partitionable via block device extended minor support. Environments
that requre the mdp style of array can always edit the configuration
file to specify auto=mdp.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The 'num_domains' field simply identifies the number of mirrors. So it
is 2 for a 2-disk raid1 or a 4-disk raid10. The orom does not currently
support more than 2 mirrors, but a three disk raid1 for example would
increase num_domains to 3.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The code for moving spares around a spare-group currently
only works for 0.90 metadata. Generalise it for 1.x metadata
as well.
Reported-by: "Garth Snyder" <garth@grsweb.us>
Signed-off-by NeilBrown <neilb@suse.de>
If someone creates/assemble an array called "/dev/md0", don't force
it to be "/dev/md/0". Doing so isn't really necessary and it
likely to confuse people.
Signed-off-by: NeilBrown <neilb@suse.de>
When rebuilding the mapfile (mdadm -Ir), if not appropriate name is
found in /dev/md/, try to find an appropriate name, either by looking
in mdadm.conf or by using the name in the metadata.
Signed-off-by: NeilBrown <neilb@suse.de>
It always afters to cast big things to (unsigned long long) before
printing as %llu - it seems there will always be one arch which
has something to complain about ....
Signed-off-by: NeilBrown <neilb@suse.de>
Rather than preferring non-standard names (of which there are
many, like /dev/block/9:1), prefer names in /dev/md/ when finding
the name of an md device.
Signed-off-by: NeilBrown <neilb@suse.de>
If an array name contains a "hostname:" prefix, then
--assemble will tend to leave it there, while --incremental
will strip it off (when chosing a device name during auto-assembly).
Make this more consistent: strip the name off if we decide that
the name will be treated as 'local'. Leave it on if it will be
treated as 'foreign'.
Signed-off-by: NeilBrown <neilb@suse.de>
Use when searching mdadm.conf for a device, use more flexible
matching that e.g. ignores leading /dev/md/ or /dev/
As mdadm now accepts both "/dev/md/foo" and "foo" is many places as
equivalent, they should compare as the same.
Signed-off-by: NeilBrown <neilb@suse.de>
If mdadm.conf contains
HOMEHOST <ignore>
or commandline contains
--homehost=<ignore>
then the check that array metadata mentions the given homehost is
replace by a check that the name recorded in the metadata is not
already used by some other array mentioned in mdadm.conf.
This allows more arrays to use their native name rather than having
an _NN suffix added.
This should only be used during boot time if all arrays required for
normal boot are listed in mdadm.conf.
If auto-assembly is used to find all array during boot, then the
HOMEHOST feature should be used to ensure there is no room for
confusion in choosing array names, and so it should not be set
to <ignore>.
Signed-off-by: NeilBrown <neilb@suse.de>
as text_version is a char array (not a pointer), testing the
address against NULL is the wrong thing to do. Test the
content instead.
Signed-off-by: NeilBrown <neilb@suse.de>
For consistency with --create and --assemble, allow the array name
given in mdadm.conf to exclude the "/dev/md/" prefix. So e.g.
ARRAY home uuid=whatever
is treated like
ARRAY /dev/md/home uuid=whatever
Also exclude names which create_mddev will reject.
Signed-off-by: NeilBrown <neilb@suse.de>
For container= and member= to be effective in an mdadm.conf line
they must both be present. So when checking for their absence we
need container != NULL || member != NULL.
Signed-off-by: NeilBrown <neilb@suse.de>
Because ---examine --brief, or --detail --brief are
often used to create mdadm.conf, and because people don't want to
have to update their mdadm.conf unnecessarily, we don't want to
include information that might change.
And now that level changing is supported, that is almost everything
but UUID.
So move some more fields into the "Only print with --verbose" class.
Signed-off-by: NeilBrown <neilb@suse.de>
The line 'auto' in mdadm.conf can be used to disable assembly
of specific metadata types, or of all arrays.
This does not affect assembly of arrays listed in mdadm.conf
or on command line.
auto -all
will disable all auto-assembly.
auto -ddf
will cause mdadm to ignore ddf arrays that are not explicitly
mentioned, and auto assemble anything else it finds.
Signed-off-by: NeilBrown <neilb@suse.de>
Sometimes we want to ensure particular arrays are never
assembled automatically. This might include an array made of
devices that are shared between hosts.
To support this, allow ARRAY lines in mdadm.conf to use the word
"ignore" rather than a device name. Arrays which match such lines
are never automatically assembled (though they can still be assembled
by explicitly giving identification information on the mdadm command
line.
Signed-off-by: NeilBrown <neilb@suse.de>
If an array is created with --homehost=any, then --assemble and
--incremental will treat it as being local to 'this' host, no matter
what the name of this host is.
This is useful for array that will be given unique names and be
moved between machines.
This needs to be documented.
Signed-off-by: NeilBrown <neilb@suse.de>
When choosing the minor number to use with an array, we currently base
the number of the 'name' stored in the metadata if that name is
numeric.
Extend that so that if it looks like a number md device name (/dev/md0
or just md0 or even /dev/md/0), then we use the number at the end to
suggest a minor number.
The means that if someone creates and array with "--name md0" or even
"--name /dev/md0" it will continue to do what they expect.
Signed-off-by: NeilBrown <neilb@suse.de>
Apparently the dereferencing of a type-punned pointer breaks strict
aliasing rules. And we wouldn't want to do that.
So just make a different array of the appropriate type and use memcpy.
Resolves-Debian-bug: 505375
Signed-off-by: NeilBrown <neilb@suse.de>
This patch enables the --size parameter for build operations.
Without this, if you have a raid1, for instance, where the 2 disks are
not the exact same size, and you need to build the array but one of the
disks is not available right at the moment (maybe it's USB and it's
unplugged, or maybe it's a network disk and it's unavailable), then you
have to play some weird games to get the array to size correctly (that
is, to the size of the smaller of the two components or less).
There may be other uses for this too...
--
Paul
Signed-off-by: NeilBrown <neilb@suse.de>
From 2.6.30, /proc/mounts and various /sys files will
probably always returns 'readable' to select, so we will need
to wait on POLLPRI to get the 'new data is available' signal.
When using select, this corresponds to an 'exception', so
adjust calls to select accordingly.
In one case we sometimes wait on a socket and sometime on
/proc/mounts, so we need to test which.
Signed-off-by: NeilBrown <neilb@suse.de>
sysfs directories for partitions do not have md/* files, but
should not for that reason be ignored.
Thanks to Michal Soltys for original fix.
Signed-off-by: Michal Soltys <soltys@ziu.info>
Signed-off-by: NeilBrown <neilb@suse.de>
During early boot, /var/run may not exist or be writable.
If that happens, sore the mapfile (which is very important for
incremental assembly) in /dev (which should exist for udev).
Thanks to Doug Ledford <dledford@redhat.com> for identify this
problem and suggesting a solution.
Signed-off-by: NeilBrown <neilb@suse.de>