On Fri, Jun 17, 2011 at 09:29:49AM -0700, jeffs_linux@xxxxxxxxxxx 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@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
