The final completion of a recovery can be delayed, so use
sync_completed to check if it is finished, just not been reaped.
Signed-off-by: NeilBrown <neilb@suse.com>
sometimes the removed device is re-added before the writes
get all the way to the md device - so the array doesn't need
any recovery and the test fails.
So flush first to be safe.
Signed-off-by: NeilBrown <neilb@suse.com>
newer versions of mkfs.extX ask before creating a filesystem
on a device which appears to already have a filesystem.
We don't want that, so add the -F flag.
Also be explicit about fs type as one shouldn't depend on defaults.
Signed-off-by: NeilBrown <neilb@suse.com>
If the name in the array has a home-host, then
require that it matches, or is "any", or requested
homehost is "any".
Signed-off-by: NeilBrown <neilb@suse.com>
... rather than relying on the caller getting them in the
correct order.
This is better engineering and fixes a bug, but because the
failed_slotX numbers are used later with assumption that
they weren't swapped
Signed-off-by: NeilBrown <neilb@suse.de>
- document meaning of various arrays. In particular:
stripes[]
blocks[]
blocks_page[]
block_index_for_slot[]
It needs to be clear if these are indexed by raid_disk
number or syndrome number.
- changed meaning of block_index_for_slot[]. It didn't seem
to be used consistently. It also made use of the block numbers
in array data ordering, which is not directly relevant for syndrome
calculations.
- reduced number of args to autorepair and manual_repair
There don't need both stripes[] and blocks[]. And they don't need
diskP or diskQ.
blocks[-1] is the P chunk, blocks[-2] is the Q chunk.
block_index_for_slot[] can be used to find the target device for
a particular syndrome block.
- remove stripe locking from within manual_repair, and instead
use the global stripe locking used for check and autorepair.
- this necessitated changes to raid6_datap_recov and raid5_2data_reov
so the P and Q blocks could be before or after the data blocks.
Signed-off-by: NeilBrown <neilb@suse.de>
Earlier patch:
56fcbcbb6f
calculated the proper chunk size - but didn't use it..
Let's actually use it this time.
Signed-off-by: NeilBrown <neilb@suse.com>
The order of devices used for the syndrome calculation is not
the same as the order of data in the array.
The D block immediately after Q is first, then they continue
cyclicly in raid-disk order, skipping over the P disk if it is seen.
This gets the 'check' right for all layouts other than DDF, which is
quite different.
I haven't confirmed that this does't break repair.
Signed-off-by: NeilBrown <neilb@suse.de>
revert-inplace would sometimes find that the original reshape had
finished.
So slow down the reshaping during --stop (which needs to be a little
bit fast so that stop doesn't timeout waiting) and don't wait quite
so long before stopping.
Signed-off-by: NeilBrown <neilb@suse.de>
This checks that raid6check finds no errors in newly created array
with all different layouts.
(it doesn't...)
Signed-off-by: NeilBrown <neilb@suse.de>
If --save-logs is given we already save all logs to --logdir
If not, we should still save erroneous logs to --logdir.
Signed-off-by: NeilBrown <neilb@suse.com>
Some actions only appear in /proc/mdstat after a little delay,
so check in sync_action as well.
This applies when checking for recovery etc, and when waiting for idle.
Signed-off-by: NeilBrown <neilb@suse.de>
If the array is reshaping to more devices, then stopping
during that initial critical section is a bad idea.
So check for it and wait a bit.
Should probably handle final critical section of a reduction
too.
same-size reshape should be handled correctly already.
Signed-off-by: NeilBrown <neilb@suse.de>
A race can allow 'completed' to read as 2^63-1, which takes
a long time to count up to.
So guard against that possibility.
Signed-off-by: NeilBrown <neilb@suse.com>
If Wait() finds the array resync is 'frozen', then wait
a little while to avoid races, but don't wait forever.
Signed-off-by: NeilBrown <neilb@suse.com>
If a read fills the whole buffer, then we possibly
missed something of the end, and we definitely shouldn't
put a '\0' beyond the end, so just return an error.
This should never happen anyway.
Signed-off-by: NeilBrown <neilb@suse.com>
A 'devnm' never starts with '/', so this test is pointless.
The code should use the passed-in devname unless it is clearly
not usable. So fix it to do that.
Signed-off-by: NeilBrown <neilb@suse.de>
These both have the same value, and have done since the
'devnm' concept was introduced.
So discard the pointless duplicate.
Signed-off-by: NeilBrown <neilb@suse.de>
'recover' etc doesn't appear in /proc/mdstat immediately.
The "sync" thread must be started first.
But 'sync_action' shows it as soon as MD_RECOVERY_NEEDED is set
in the kernel. So look there too.
Now maybe I can get rid of some of those silly 'sleep' calls.
Signed-off-by: NeilBrown <neilb@suse.de>
If an array is being reshaped using backup space on a 'spare' device,
then
mdadm --grow --continue
won't find it as by the time it runs, nothing looks like a spare are
more. The spare has been added to the array, but has no data yet.
So allow reshape_prepare_fdlist to find a newly-incorporated spare and
report this so it can be used.
Reported-by: Xiao Ni <xni@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When the array is stopped during a critical section, we sometimes
erase the backup, which is bad.
This happens when 'completed' is zero.
This can happen easily when 'stop' freezes reshape.
So try to be more careful and check 'reshape_position'.
Signed-off-by: NeilBrown <neilb@suse.de>
Appologies if this is the wrong mailing list for this patch.
This is a very small patch for the manual page for the mdadm utility.
Thanks,
Andrew
Signed-off-by: NeilBrown <neilb@suse.de>
Function add_new_arrays() expects that function get_md_name() should
return pointer to devname, but also get_md_name() may return NULL. So
check the pointer before use it in add_new_arrays().
Signed-off-by: Sergey Vidishev <sergeyv@yandex-team.ru>
Signed-off-by: NeilBrown <neilb@suse.de>
sometimes these can get left around, and udev can be looking
at them at awkward times so they don't disappear.
So be forceful.
Signed-off-by: NeilBrown <neilb@suse.de>
Some old kernels set 'completed' to '0' too soon.
But modern kernels don't.
And when 'mdadm --stop' freezes and resume the grow,
'completed' goes back to zero briefly, which can confuse this
logic.
So only think '0' might be wrong from an old kernel when
the reshape has gone idle.
Signed-off-by: NeilBrown <neilb@suse.de>
EBUSY can be returned if something has recently happened
to cause md to want to check if recovery is needed, but hasn't
had a chance yet.
This can easily happen in testing.
So retry a few times in that case.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ use correct data-offset for cmp - that has changed.
2/ flushbufs on the block device before reading to avoid cache issues
Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown
NeilBrown
Andrew Burgess
Sergey Vidishev