mirror of
git://sourceware.org/git/lvm2.git
synced 2024-12-22 17:35:59 +03:00
8ab0725077
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 |
||
|---|---|---|
| .. | ||
| activate | ||
| cache | ||
| cache_segtype | ||
| commands | ||
| config | ||
| datastruct | ||
| device | ||
| display | ||
| error | ||
| filters | ||
| format1 | ||
| format_pool | ||
| format_text | ||
| freeseg | ||
| label | ||
| locking | ||
| log | ||
| lvmpolld | ||
| metadata | ||
| mirror | ||
| misc | ||
| mm | ||
| notify | ||
| properties | ||
| raid | ||
| replicator | ||
| report | ||
| snapshot | ||
| striped | ||
| thin | ||
| unknown | ||
| uuid | ||
| zero | ||
| Makefile.in | ||