[linux-lvm] LVM RAID5 out-of-sync recovery

[Heinz Mauelshagen]

On 10/12/2016 09:15 AM, Giuliano Procida wrote:
> On 12 October 2016 at 07:57, Giuliano Procida
> <giuliano.procida at gmail.com> wrote:
>>>   array_position=4294967295
>> This should be 1 instead. This is 32-bit unsigned 0xf...f. It may be
>> that it has special significance in kernel or LVM code. I've not
>> checked beyond noticing one test: role < 0.
> http://lxr.free-electrons.com/source/drivers/md/dm-raid.c
>
> Now role is an int and the RHS of the assignment is le32_to_cpu(...)
> which returns a u32. Testing < 0 will *never* succeed on a 64-bit
> architecture.
Well, the result of le32_to_cpu is assigned to a 32 bit int on 64 bit arch.

The 4294967295 reported by parse_rmeta will thus result in signed int 
role = -1
which is used for comparision.

The tool should rather report the array_position signed to avoid iritation.



>   This is a kernel bug. If the code is changed so that
> role is also u32 and the test is against ~0, it's possible that
> different, better things will happen. Please try reporting this to the
> dm-devel people.
>
> I still don't know what wrote that value to the superblock though.

Must have been the position gotten set to -1 indicating failure to hot add
the image LV back in and thus MD has written it to that superblock.

Did you spot any "Faulty.*device #.*has readable super block.\n 
Attempting to revive it."
messages from dm-raid in the kernel log by chance?

Heinz

>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/