7 Commits

Author	SHA1	Message	Date
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	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