On 10/12/2016 09:15 AM, Giuliano Procida wrote:
On 12 October 2016 at 07:57, Giuliano Procida
<giuliano.proc...@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@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
