Change how sudden-degraded devices should appear.
We don't record failure, we record that the device isn't there.
Signed-off-by: NeilBrown <neilb@suse.de>
If we assemble a newly-degraded array, the missing devices must be marked
as 'failed' so we don't expect them in future.
Signed-off-by: NeilBrown <neilb@suse.de>
Getting the major number from the hex device number should take
all-but-the-last-two digits, rather than just the first two digits.
Signed-off-by: NeilBrown <neilb@suse.de>
This is a test simulating two temporary missing disks. These will
have less recent meta data than the other disks in the container.
When the array is reassembled, we expect mdadm to detect that
and react to it by using the meta data of the more recent disks
as reference.
This test FAILS with mdadm 3.3 for DDF.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
This is a test case for handling incremental
assembly correctly after disks had been missing once.
This test is the basis for other similar but more tricky
test cases involving inconsitent meta data.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
A test for my recent patch "Monitor: write meta data in readonly state,
sometimes". Test that a faulty disk is recorded in the meta data.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
This is similar to 10ddf-fail-readd. The difference is that the
array is stopped and incrementally assembled before the disk is
re-added.
Signed-off-by: NeilBrown <neilb@suse.de>
Some ddf tests scripts assume that /dev/sda is always present.
That's wrong e.g. on VMs. Use a more general approach.
Signed-off-by: NeilBrown <neilb@suse.de>
If a disk fails and simulaneously a new array is created, a race
condition may arise because the meta data on disk doesn't reflect
the disk failure yet. This is a test for that case.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
This is one more unit test for failure/recovery, this time with
double redundancy, which isn't covered by the other tests.
Signed-off-by: NeilBrown <neilb@suse.de>
This test has some randomness because it is not always deterministic
which of the two arrays gets the spare and which remains degraded.
Handle it.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
helper functions to determine the list of devices in an array,
etc.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
I forgot to check in this helper script, similar to the one for IMSM.
It is needed by tests/10ddf-create-fail-rebuild.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
This test adds a new unit test similar to 009imsm-create-fail-rebuild.
With the previous patches, it actually succeeds on my system.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
Let the first created array be RAID5 rather than RAID0. This makes
the test harder than before, because everything after the first
Create has do be done indirectly through mdmon.
Signed-off-by: NeilBrown <neilb@suse.de>
This patch adds RAID10 support to the DDF test script.
It actually passes!
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
Linux 3.10 will allow more "--add" to be handled as "--re-add".
To be sure the tests work correctly we sometimes need to zero
the device to ensure it really is an --add that happens.
Signed-off-by: NeilBrown <neilb@suse.de>
The test script was counting output lines - its expectations
don't match the current code any more. Remove this pointless
test.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
commit cb19a251a5
super1: reserve at least 2 chunks for reshape headroom.
reserved more space in a RAID5, so we need to update to array
sizes when reshaping.
Also make sure reshape tests we change the shape: raid5->raid1
was failing and we didn't notice.
Signed-off-by: NeilBrown <neilb@suse.de>
When calling raid6check in regular scanning mode, specifiying
"autorepair" as the last positional parameter will cause it
to automatically repair any single slot failes it identifies.
Signed-off-by: NeilBrown <neilb@suse.de>
In repair mode, the data block indices to be repaired were calculated
using geo_map() which returns the disk slot for a data block index
and not the reverse. Now we simply store the reverse of that calculation
when we do it anyway.
Signed-off-by: NeilBrown <neilb@suse.de>
We need to set speed_limit_min accordingly, otherwise setting
speed_limit_max below 1000 will have no effect.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This test is quite sensitive to resync speed - if the resync happens
to quickly it fails because it sees aan optimal array when it expects
a degraded array.
1000 is often slow enough but now always, so slow it down even more.
This requires reducing speed_limit_min also as kernel ignores 'max'
when speed is below 'min'.
Reported-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
In repair mode, raid6check will rewrite one single stripe
by regenerating the data (or parity) of two raid devices that
are specified via the command line.
If you need to rewrite just one slot, pick any other slot
at random.
Note that the repair option will change data on the disks
directly, so both the md layer above as well as any layers
above md (such as filesystems) may be accessing the stripe
data from cached buffers. Either instruct the kernels
to drop the caches or reassemble the raid after repair.
Signed-off-by: NeilBrown <neilb@suse.de>
To match the add-bitmap tests, here is a set of tests checking the
removal of bitmaps.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown
mwilck@arcor.de
Gilles Espinasse
Robert Buchholz
Jes Sorensen