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>
This set of tests verifies that it is possible to add an internal
bitmap to an existing array, and that the device can be written to
after the bitmap is added. This should catch cases such as the one
fixed by 4474ca42e2577563a919fd3ed782e2ec55bf11a2
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When running the mdadm testsuite on ppc64 with a 64kB page size I
see a couple of failures because the chunk size is smaller than a
page.
Bump the chunksize to 64kB to fix these failures.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: NeilBrown <neilb@suse.de>
Some systems do not ship the md multipath module. If not available
simply skip any multipath tests.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
A recent change means that devices smaller than
1Gig no longer have 1Meg wasted at the start.
So we must adjust some sizes again.
Signed-off-by: NeilBrown <neilb@suse.de>
RAID1 arrays don't have a chunk size, but if you ever convert
one to RAID5 you will need at least a small one >= 4K.
So round of size to a multiple of 64K.
This only affect Create, not "--grow --size=max". The latter
is too hard and with smaller returns.
Signed-off-by: NeilBrown <neilb@suse.de>
In this test we stop and restart an array that is being recovered,
and we do that several times. Sometimes it completes the recovery
before we expect and test results are wrong.
So slow it down a bit more.
Signed-off-by: NeilBrown <neilb@suse.de>