[linux-lvm] LVM RAID repair trouble

[Giuliano Procida]

On 28 September 2016 at 07:51, Giuliano Procida
<giuliano.procida at gmail.com> wrote a load of rubbish:
> On 26 September 2016 at 08:54, Giuliano Procida
> <giuliano.procida at gmail.com> wrote:
>> The net effect is that I now have RAID volumes in an odd state with
>> extracted / missing images (I think just a cosmetic issue) and which
>> rebuild on every boot (or rather re-activation and use).
>> The volumes take a long time to resync, especially concurrently!
>
> I'm mostly interested in fixing my system but I had a look at the
> stderr for the last repair attempt. If I had to make a guess, it would
> be that lvconvert is racing against state changes in the kernel and
> eventually asking dm-raid to set up an array with mismatched
> expectations about whether device 0 should be flagged for rebuild or
> not.
>
> Looking through the LVM code, there is clearly an effort to clear
> rebuild flags to prevent just the problem I'm having. Unfortunately,
> with lvconvert exiting early these paths are presumably not taken. I
> also noticed that the rebuild flag is singled out for exclusion when
> generating (backup?) metadata.

The last bit's not true. Also, I *do* have consistently REBUILD flags
in the on-disk and backed up metadata for the new rmeta and rimage
subLVs. I must have been grepping a typo.

The questions still remain:

> How can I clear REBUILD safely?

vgcfgrestore -t and the source code show that trying this will fail
until I lvconvert --repair everything off the missing PV and vgreduce
--removemissing.

The only other thing I can think of at present is to overwrite the
text [, "REBUILD"] with spaces and recalculate and re-write the CRC
for the metadata; sync and power off the machine (well after running
various LVM commands that read the on-disk format!).

> Can I renumber _5 to _0 as well at the same time?
> Does it make sense to try the latest version of LVM user space tools
> to try the final repair conversions?
>
> --gp