1
0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-22 17:35:59 +03:00
Commit Graph

12 Commits

Author SHA1 Message Date
David Teigland
3bcc6c7e60 tests: drop lvmetad bits 2018-09-10 11:49:11 -05:00
David Teigland
885eb2024f tests: enable non-working tests with lvmlockd
Those that are failing for reasons other than lvmlockd
restrictions.
2018-05-31 16:18:53 -05:00
Jonathan Brassow
5013032845 testsuite: Add and document a 'should' for "idle" -> "recover" RAID test
When a "recover" is just starting for a RAID LV, it is possible to get
"idle" for the sync action if the status is issued quickly enough.  This
is fine, the MD thread just hasn't gotten things going yet.  However,
the /need/ for a "recover" should be marked in md->recovery and it would
be simple enough to fix the kernel so this doesn't happen.  May eventually
want a separate bug for this, but for now it fits with RHBZ 1507719.
2017-11-02 08:53:48 -05:00
Jonathan Brassow
bc29785d09 test: clean-up failing test case and document 'should' cases
There are two known bugs in the lvconvert-raid-status-validation.sh
test.  The first one I consider to be more of an annoyance (1507719).
The second one I consider to be more serious (1507729).

RHBZ 1507719 simply documents the fact that the three RAID status
fields may not always be coherent due to the way they are set and
unset when the MD thread is shutting down and starting up.  For
example, the sync ratio may be 100% but the sync action may not
yet have switched to "idle" and the health characters may not yet
all be 'A's (i.e. the devices set to InSync).

RHBZ 1507729 is more serious.  The sync ratio can be 100% for a
short period of time after upconverting linear -> RAID1.  It is
reset to 0 once the MD sync thread gets to work on it.  It does
this because, technically, the array /is/ in-sync if the new
devices are excluded - i.e. the data is 100% available and
consistent.  I'm not sure what to do about this problem, but we'd
much rather not have this state that looks exactly like the
end of the process when the sync ratio is 100% because the
"recover" process finished, but the sync action and health
characters haven't been updated yet.  Put simply, the problem
is that we can't tell if a sync is starting or finished based
on the status output.
2017-10-30 21:58:38 -05:00
Jonathan Brassow
38f7fbac64 clean-up: Correct the comment to match the particular test case 2017-10-24 14:06:44 -05:00
Heinz Mauelshagen
d6f4563103 test: remove 'should's from test to test target status race fix 2017-10-19 17:41:44 +02:00
Zdenek Kabelac
160cb1e713 tests: replace cat usage 2017-07-10 14:23:53 +02:00
Zdenek Kabelac
e55bae2b2c tests: use bash 2017-07-10 14:23:53 +02:00
Zdenek Kabelac
24751b45bd tests: double quote 2017-07-10 14:23:53 +02:00
Zdenek Kabelac
5ca4fd0478 tests: correcting usage of '==' in bash 2017-07-10 14:23:53 +02:00
Jonathan Brassow
915d20d0e6 test: New test file for validating kernel status during sync ops
New tests to add checking for '100%' in-sync at start of "recover"
process (it shouldn't happen, but I've seen it before).  Also,
check status over the whole cycle of various sync processes ("resync"
and "recover").
2017-06-16 10:16:07 -05:00
Jonathan Brassow
3592243afb test: New test file for validating kernel status during sync ops
First test in this file checks whether 'aa' is ever spotted during
a "recover" operation (it should not be).  More tests should follow
in this file to look for oddities in status output - especially as
it relates to the sync_ratio, dev_health, and sync_action fields.
2017-06-15 11:06:08 -05:00