As a some/most bootloaders don't understand md metadata, it might
be difficult to boot off an array with the default 1.0 metadata.
So if this is used for a RAID1, ask for confirmation.
Signed-Off-By: NeilBrown <neilb@suse.de>
As --add can destroy important data on a disk, and
--re-add is not suppose to, it is wrong to silently
try --add if --re-add fails.
So print a message and abort instead.
Signed-off-by: NeilBrown <neilb@suse.de>
->validate_geometry is called to validate overall parameters,
and to validate each individual device.
If it ever fails, it needs to report the reason, as common code
cannot possible know.
Signed-off-by: NeilBrown <neilb@suse.de>
A small bitmap-chunksize hurts performance without helping
resync speed much - particularly on internal bitmaps.
So set the default to at least 64Meg.
Signed-off-by: NeilBrown <neilb@suse.de>
1.1 is more flexible in a number of ways and is safer.
0.90 is still fully supported.
1.0 should possibly be used for RAID1 arrays that you
want to boot off, depending on your boot loader.
Signed-off-by: NeilBrown <neilb@suse.de>
This seems more appropriate for current (and recent) model drives than
64K.
64K is still the default for '--build' as changing that could corrupt
data.
64K is also the default rounding for 'linear' on kernels older than
2.6.16.
Signed-off-by: NeilBrown <neilb@suse.de>
Other metadata formats already did not worry about whether 'sync' was
missing or not. super0 needs that now, but only for 0.91 metadata
that is undergoing reshape.
Signed-off-by: NeilBrown <neilb@suse.de>
Previously such things did not exist: ACTIVE and SYNC were either both
set or both clear. Recent changes with reshape means that a device
can be ACTIVE but not yet fully in-sync, so they need to be handled
and included in the array as active devices.
Signed-off-by: NeilBrown <neilb@suse.de>
A change the reduces the size of an array always happens
before any other change. So it can cause data to be lost.
By themselves these changes are reversible. But once another
change has started, the data would be permanently lost.
So recommend data integrity be checked between a size change
and any other change.
Signed-off-by: NeilBrown <neilb@suse.de>
2.6.31 has a bug which can lead to unsafe reshaping.
So only allow a reshape with 2.6.32.
When the required fixed get into 2.6.31.y, this can be relaxed
slightly
Signed-off-by: NeilBrown <neilb@suse.de>
We were using ->component_size while it hadn't been set.
This effectively meant that 'blocks' wasn't multiplied by
16 and reshape was even slower than it should have been.
Signed-off-by: NeilBrown <neilb@suse.de>
If an array goes degraded during reshape, we need to
adjust the devices we read from so as not to back up
stale data.
Signed-off-by: NeilBrown <neilb@suse.de>
The 'arraystart' is in sectors while restore_stripes requires
bytes, so we need a conversion.
Without this, backups get restored to the wrong offset.
Reported-by: "KueiHuan Chen" <kueihuan.chen@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
One should use
/sbin/blkid -o udev -p ...
(from util-linux >> 2.16) instead of
vol_id --export ...
Author: Marco d'Itri <md@linux.it>
Bug-Debian: http://bugs.debian.org/541884
Reviewed-by: martin f. krafft <madduck@debian.org>
Signed-off-by: NeilBrown <neilb@suse.de>
LANG=C man --warnings -l mdadm.8 > /dev/null
complains that '.XX' is an invalid macro.
This is not correct. The sequence
.ig XX
anything can go here
.XX
is correct and is ignored (see 'info groff' and the 'ig' index
entry).
However the same can be achieved with
.ig
anything can go there
..
and this produces no warnings, so use that instead.
Signed-off-by: NeilBrown <neilb@suse.de>
As mdadm is normally a short-lived program it isn't always necessary
to free memory that was allocated, as the 'exit()' call will
automatically free everything. But it is more obviously correct if
the 'free' is there.
So this patch add a few calls to 'free'
Signed-off-by: NeilBrown <neilb@suse.de>
Originally the backup-metadata was only written once at the
start of a raid5 reshape that made the array bigger. So we only
set the mtime once.
Now that we can be writing metadata continually during an in-place
reshape, we need to update the mtime more often.
Also, allow the metadata mtime to be slightly in advance of the
array mtime. Normally the difference will be less than a second,
so 10 minutes should be plenty. This guards against an old backup
file being used to restart an array. but starting two reshapes in the
10 minutes is sufficiently unlikely, and the possibility of an
accident is already sufficiently small, that 10 minutes is probably
fine.
Thanks to Guy Martin <gmsoft@tuxicoman.be> for discovering and
reporting that .mtime wasn't being updated properly.
Signed-off-by: NeilBrown <neilb@suse.de>
I think we sometime get way ahead of udev and devices disappear
and appear almost at random. So add some settling.
Signed-off-by: NeilBrown <neilb@suse.de>
ie. the percent increments after which RebuildNN event is generated
This is particulary useful when using --program option, rather than
(only) syslog for alerts.
Signed-off-by: Zdenek Behan <rain@matfyz.cz>
Signed-off-by: NeilBrown <neilb@suse.de>
mlockall(MCL_FUTURE) only locks mappings that have not yet
been created. To lock all memory used by the process, we need
MCL_CURRENT | MCL_FUTURE
Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown
Marco d'Itri
Mike Frysinger
Zdenek Behan