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

6 Commits

Author SHA1 Message Date
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
51b9de7249 tests: better disk delay
Delay only writable extents.
Skip zeroing for earlier lvcreate finish.
2017-03-16 08:49:52 +01:00
Heinz Mauelshagen
43fb4aa69b test: add delay to lvchange-raid1-writemostly.sh
Commit 8ab0725077 introduced this new test.

Add a read delay to the PVs to avoid a race
in the script causing the test to fail.

Correct comment.
2017-03-07 15:18:13 +01:00
Heinz Mauelshagen
17838e6439 test: fix typo 2017-03-03 23:22:29 +01:00
Heinz Mauelshagen
8ab0725077 lvchange: reject writemostly/writebehind on raid1 during resync
The MD kernel raid1 personality does no use any writemostly leg as the primary.

In case a previous linear LV holding data gets upconverted to
raid1 it becomes the primary leg of the new raid1 LV and a full
resynchronization is started to update the new legs.

No writemostly and/or writebehind setting may be allowed during
this initial, full synchronization period of this new raid1 LV
(using the lvchange(8) command), because that would change the
primary (i.e the previous linear LV) thus causing data loss.

lvchange has a bug not preventing this scenario.

Fix rejects setting writemostly and/or writebehind on resychronizing raid1 LVs.

Once we have status in the lvm2 metadata about the linear -> raid upconversion,
we may relax this constraint for other types of resynchronization
(e.g. for user requested "lvchange --resync ").

New lvchange-raid1-writemostly.sh test is added to the test suite.

Resolves: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855895
2017-02-23 15:09:29 +01:00