Current "mdadm --run /dev/mdX" will not handle external metadata
properly. mdmon won't be started etc.
So use the code from "mdadm -IRs" instead - that already does all
the right things.
Reported-by: Francis Moreau <francis.moro@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This call to validate_geometry is really rather gratuitous.
It is purely about the fact that super0 cannot use more than 4TB.
So just make it an explicit test - less confusing that way.
With this, validate_geometry is only called from Create, which
makes it easier to reason about.
Also validate_geometry is now never passed NULL for the 'chunk'
parameter, so we can remove those annoying tests for NULL.
Signed-off-by: NeilBrown <neilb@suse.de>
If we stop too soon after reshape starts (probably only during
testing), we can get confused by the status of the reshape.
If that might be happening - sleep a bit longer.
Also allow for reshape going unusually slowly (again, probably only
during testing).
Signed-off-by: NeilBrown <neilb@suse.de>
It is possible for 'sync_completed' to be further ahead than
we deduced from 'reshape_position'. However we cannot read it while
the array is frozen, so it is hard to know.
Once that array is unfrozen, check and if sync_completed is ahead of
'sync_max', push 'sync_max' well ahead if 'sync_completed' so it
will all synchronise up properly.
Signed-off-by: NeilBrown <neilb@suse.de>
To be able to revert-reshape of raid4/5/6 which is changing
the number of devices, the reshape must has been stopped on a multiple
of the old and new stripe sizes.
The kernel only enforces the new stripe size multiple.
So we enforce the old-stripe-size multiple by careful use of
"sync_max" and monitoring "reshape_position".
Signed-off-by: NeilBrown <neilb@suse.de>
Manage_runstop has an open-coded version of use_udev() which is no
longer correct. So make it use use_udev() explicitly.
Signed-off-by: NeilBrown <neilb@suse.de>
A RAID10 array can have 'sets' of devices which are reported by
--detail.
They can now be collectively failed or removed.
Signed-off-by: NeilBrown <neilb@suse.de>
When stopping an mdmon array, at reshape might be being aborted
which inhibets O_EXCL. So if that is possible, call flush_mdmon
to make sure mdmon isn't still busy.
Reported-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
There are a number of fields which should not
be left uninitialised. e.g. attempt_re_add can get
confused if ->writemostly is not set correctly.
Signed-off-by: NeilBrown <neilb@suse.de>
When asked to incrementally-remove a device, try marking the array
read-auto first. That will delay recording the failure in the
metadata until it is really relevant.
This way, if the device are just unplugged when the array is not
really in use, the metadata will remain clean.
If marking the default as faulty fails because it is EBUSY, that
implies that the array would be failed without the device. As the
device has (presumably gone) - that means the array is dead. So try
to stop it. If that fails because it is in use, send a uevent to
report that it is gone. Hopefully whoever mounted it will now let go.
This means that if you plug in some devices and they are
auto-assembled, then unplugging them will auto-deassemble relatively
cleanly.
To be complete, we really need the kernel to disassemble the array
after the last close somehow. Maybe if a REMOVE has failed and a STOP
has failed and nothing else much has happened, it could safely stop
the array on last close.
Signed-off-by: NeilBrown <neilb@suse.de>
We widely use a "devnum" which is 0 or +ve for md%d devices
and -ve for md_d%d devices.
But I want to be able to use md_%s device names.
So get rid of devnum (a number) and use devnm (a 32char string).
eg.
md0
md_d2
md_home
Signed-off-by: NeilBrown <neilb@suse.de>
mdadm /dev/mdXX --re-add faulty
will identify any faulty devices in the array, remove them, and
--re-add them.
Signed-off-by: NeilBrown <neilb@suse.de>
A recent change to improve error messages for subdev management broken
all use cases were device names like %d:%d were used.
Re-arrange the code again so we use dev_open first - which understands
those names - and then only try 'stat' if that failed.
The important thing is to base the 'Cannot find' message on the result
of 'stat', not on the result of 'open'.
Signed-off-by: NeilBrown <neilb@suse.de>
As dev_open uses O_DIRECT it will fail on directories and such.
So we never get to report that it isn't a block device.
So do a 'stat' earlier and if it is a block device, report the
error there.
Signed-off-by: NeilBrown <neilb@suse.de>
--replace can be used to replace a device without completely failing
it. Once the replacement completes the device will be failed.
--with can indicate which of several spares to use.
Signed-off-by: NeilBrown <neilb@suse.de>
mdadm --create /dev/md0 .... /dev/sda1:1024 /dev/sdb1:2048 ...
The size is in K unless a suffix: K M G is given.
The suffix 's' means sectors.
Signed-off-by: NeilBrown <neilb@suse.de>
This is currently only useful for 1.x metadata and will allow an
explicit --data-offset request on command line.
Signed-off-by: NeilBrown <neilb@suse.de>
We must only remove from a container if the device isn't a
member of any member array.
To check we look at the 'holders' directory in sysfs.
We currently skip that check if ->devname is "detached", however
that can never be true since the change that introduced
add_detached().
Also sysfs_unique_holder returns status in 'errno' which isn't
entirely safe as e.g. closedir() is probably allowed to clear it.
So make sysfs_unique_holder return an unambigious value, and us
it to decide what to report.
Signed-off-by: NeilBrown <neilb@suse.de>
'external' arrays don't support --re-add yet so old metadata is no
value, and 'ddf' gets confusing in mdmon if old metadata is found.
So for now, zero out any old metadata found before adding a spare to
an externally-managed array.
Reported-by: Albert Pauw <albert.pauw@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This patch fixes the following make everything compilation error:
Manage.c: In function ‘Manage_add’:
Manage.c:538: error: ‘dev_st’ may be used uninitialized in this function
make: *** [mdadm.Os] Error 1
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This makes Manage_subdevs smaller, and makes the error-path handling
for Manage_add much cleaner and probably less buggy.
Signed-off-by: NeilBrown <neilb@suse.de>
The indent level is way too deep here, and this is a well defined
task, so split it out to a separate function.
Signed-off-by: NeilBrown <neilb@suse.de>
'st' is use to examine the metadata on the device being added
to see if a 're-add' is possible. However it is loaded long before
the 're-add' attempt is made.
So move the 'load_super' closer to were it is used - allowing us to
discard a number of 'free_super' call - and rename it to 'dev_st'
to emphasize that it related to the current device.
Signed-off-by: NeilBrown <neilb@suse.de>
We currently have rather hard-to-follow loop to iterate
through all the matches for 'missing' or 'faulty' or 'detached'.
Simplify it by creating a list of possible devices for each
of those and splicing the new list into the device list.
This removes the need for 'jnext' and 'next' and various other hacks.
Signed-off-by: NeilBrown <neilb@suse.de>
If we change some functions to accept 'verbose', where <0 means to be
quiet, in place of 'quiet', then we will be able to merge
'quiet' and 'verbose' together for simplicity.
Signed-off-by: NeilBrown <neilb@suse.de>
malloc should never fail, and if it does it is unlikely
that anything else useful can be done. Best approach is to
abort and let some super-daemon restart.
So define xmalloc, xcalloc, xrealloc, xstrdup which don't
fail but just print a message and exit. Then use those
removing all the tests for failure.
Also replace all "malloc;memset" sequences with 'xcalloc'.
Signed-off-by: NeilBrown <neilb@suse.de>
The restriction that --add was not allowed on a device which
looked like a recent member of an array was overly harsh.
The real requirement was to avoid using --add when the array had
failed, and the device being added might contain necessary
information which can only be incorporated by stopping and
re-assembling with --force.
So change the test to reflect the need.
Reported-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When we can for devices using GET_DISK_INFO we currently
limit to 1024. But some arrays can have more than this.
So raise it to 4096 and make the constant a #define.
Signed-off-by: NeilBrown <neilb@suse.de>
If the kernel supports it, freeze recovery over multiple adds,
so that they can all be added to the array at the same time and
be recovered in parallel.
Signed-off-by: NeilBrown <neilb@suse.de>
If both "legs" of a RAID1 (or equivalent in RAID10) fail, then one
of the becomes available again it maybe appropriate to re-add the
failed device(s).
So remove the restriction that an array must has 'enough' devices
before being re-added, and if there is no-where to read a superblock
from for matching, then assume the kernel will do necessary checks.
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>
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>
NeilBrown
Lukasz Dorau
Jes Sorensen
Doug Ledford