This data loss is caused by the MD kernel raid1 personality to not use
any writemostly leg as the primary.
In this case the previous linear root LV holding the populated root fs
became the primary leg of an
upconverted 2-legged raid1 which is still in the process of
synchronization to the new second raid1 leg
by the time writemostyl is set on it.
I.e. the second, new leg does not contain all data from the primary leg yet.
Setting the primary leg to writemostly causes the MD runtime to switch
the primary
to the second leg carrying on to resycnhronise the firts leg from it
hence causing the data loss.
lvchange has a bug not preventing this, so refrain from setting
writemostly on raid1 upconverted linear LVs!
Got a fix in testing to be upstreamed shortly.
Heinz
