Bug or not? Same array reports different/transformed UUID depending oncheck-method used.

I suppose I should split this into its own thread rather than burying it
in my other.

Question first:

I have two arrays attached to my Linux box. Two methods of checking
for arrays UUIDs give different results. Why, and can I reply on
these arrays?

Details follow:

Checking with,

mdadm --incremental --rebuild-map
mdadm --detail --scan
ARRAY /dev/md/0_0 metadata=0.90
UUID=52f5b43c:e83f7e2a:be6ad32e:0536ab0e
ARRAY /dev/md127 metadata=1.2 name=jeffadm:jeffadm1
UUID=d47afb79:e5fa9b28:ff35c586:f2602920

and,

cat /dev/.mdadm/map
md126 0.90 52f5b43c:e83f7e2a:be6ad32e:0536ab0e /dev/md/0_0
md127 1.2 79fb7ad4:289bfae5:86c535ff:202960f2 /dev/md127

Staring at those UUIDs, I notice that one array's UUIDs match exactly
for the two methods of checking,

/dev/.mdadm/map /dev/md/0_0 52f5b43c:e83f7e2a:be6ad32e:0536ab0e
mdadm --detail --scan /dev/md/0_0 52f5b43c:e83f7e2a:be6ad32e:0536ab0e

but the OTHER array's two UUIDs

/dev/.mdadm/map /dev/md127 79fb7ad4:289bfae5:86c535ff:202960f2
mdadm --detail --scan /dev/md127 d47afb79:e5fa9b28:ff35c586:f2602920

are 'transforms' of one another; e.g.,

mdadm --detail --scan /dev/md127 d47afb79:e5fa9b28:ff35c586:f2602920

d4 e5
7a fa
fb 9b
79: 28:...

|
| couplet order transform
|

d4 e5
7a fa
fb 9b
79: 28: ...

/dev/.mdadm/map /dev/md127 79fb7ad4:289bfae5:86c535ff:202960f2

Why are /dev/md127's UUIDs, unlike /dev/md/0_0's, reporting mis-matched
& 'transformed'?

jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Bug or not? Same array reports different/transformed UUID

On Fri, Jun 17, 2011 at 09:29:49AM -0700, jeffs_linux@123mail.org wrote:
>I suppose I should split this into its own thread rather than burying it
>in my other.
>
>Question first:
>
> I have two arrays attached to my Linux box. Two methods of checking
> for arrays UUIDs give different results. Why, and can I reply on
> these arrays?
>
>Details follow:
>
>Checking with,
>
> mdadm --incremental --rebuild-map
I don't think this is a valid method for checking array uuid.

> cat /dev/.mdadm/map
> md126 0.90 52f5b43c:e83f7e2a:be6ad32e:0536ab0e /dev/md/0_0
> md127 1.2 79fb7ad4:289bfae5:86c535ff:202960f2 /dev/md127
>
>Staring at those UUIDs, I notice that one array's UUIDs match exactly
>for the two methods of checking,
>
> /dev/.mdadm/map /dev/md/0_0 52f5b43c:e83f7e2a:be6ad32e:0536ab0e
> mdadm --detail --scan /dev/md/0_0 52f5b43c:e83f7e2a:be6ad32e:0536ab0e
>
>but the OTHER array's two UUIDs
>
> /dev/.mdadm/map /dev/md127 79fb7ad4:289bfae5:86c535ff:202960f2
> mdadm --detail --scan /dev/md127 d47afb79:e5fa9b28:ff35c586:f2602920
>
>are 'transforms' of one another; e.g.,
....
>Why are /dev/md127's UUIDs, unlike /dev/md/0_0's, reporting mis-matched
>& 'transformed'?
>
mdadm internally stores an uuid as an array of four 32bit integers
on disk it is different.
superblock version 0 (md0_0) stores 4 32bit values in host endian order(*)
(little-endian on x86)
superblock version 1 (md127) stores 16 8bit values in human readable
format (humans at least in western world countries are big endian)

The map_file, on the contrary, is always read and written as 4 32bit
values in host endian order, so on x86 machines you will find it
swapped.

Summary: the mapfile is for mdadm internal use only, use mdadm commands
(--detail, --examine) to obtain data.

(*) http://en.wikipedia.org/wiki/Endianness


L.

--
Luca Berra -- bluca@comedia.it
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Bug or not? Same array reports different/transformed UUID depending on check-method used.

On Tue, 21 Jun 2011 07:42 +0200, "Luca Berra" wrote:
> The map_file, on the contrary, is always read and written as 4 32bit
> values in host endian order, so on x86 machines you will find it
> swapped.
>
> Summary: the mapfile is for mdadm internal use only, use mdadm commands
> (--detail, --examine) to obtain data.
>
> (*) http://en.wikipedia.org/wiki/Endianness

Ok.

How might that explain that one array IS 'swapped', and the other is
not? They're both on the same machine?

jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html