raid5 endian question....

raid5 endian question....

[Aaron Botsis]

Hello,

I'm attempting to move a raid5 array from a big endian ppc machine to  
a little endian x86.
Upon trying to import the array, I get:
mdadm: No super block found on /dev/hde1 (Expected magic a92b4efc,  
got fc4e2ba9)

I assume this to be an endianess issue...
Is this a bug? Is just the magic number whacked? or are the  
superblock data structures too?

what's the best way to fix this?

Many thanks in advance.

-Aaron

Re: raid5 endian question....

[Paul Clements]

Aaron Botsis wrote:
> I'm attempting to move a raid5 array from a big endian ppc machine to  a 
> little endian x86.

> Upon trying to import the array, I get:
> mdadm: No super block found on /dev/hde1 (Expected magic a92b4efc,  got 
> fc4e2ba9)

> I assume this to be an endianess issue...

Yes.

> Is this a bug? Is just the magic number whacked? or are the  superblock 
> data structures too?

The version 0.90 superblock is not "endian agnostic". It records data in 
whatever endian order the host machine is (Version 1 superblocks, by the 
way, fix this, but are not available unless you have the latest 2.6 
kernel and mdadm).

> what's the best way to fix this?

Unfortunately, I don't think there's an easy way. But, if you can get 
the array back up on the original machine and copy down all the 
information (or if you already have it) then you can re-create the array 
on the x86 machine using "mdadm -C", but be careful... :)

--
Paul

Re: raid5 endian question....

[Aaron Botsis]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jun 19, 2005, at 5:05 PM, Paul Clements wrote:

> Aaron Botsis wrote:
>
>> Is this a bug? Is just the magic number whacked? or are the   
>> superblock data structures too?
>>
>
> The version 0.90 superblock is not "endian agnostic". It records  
> data in whatever endian order the host machine is (Version 1  
> superblocks, by the way, fix this, but are not available unless you  
> have the latest 2.6 kernel and mdadm).
>

So it's really only the superblock, then? Does that mean the parity  
stripes don't suffer from endian problems as well?


>
>> what's the best way to fix this?
>>
>
> Unfortunately, I don't think there's an easy way. But, if you can  
> get the array back up on the original machine and copy down all the  
> information (or if you already have it) then you can re-create the  
> array on the x86 machine using "mdadm -C", but be careful... :)

By information, I'm assuming you mean chunk size, parity algo, etc?   
So I can just whack a new superblock on top and all will be well  
because the parity stripes will be cool?

what's what look like:
mdadm -C -c bleh -level=5 --parity=left --raid-devices=3 /dev/md0 / 
dev/hda1 /dev/hdb1 /dev/hdc1

??
Also, I thought I noticed the array in degraded mode (probably a  
failed read or something) before the machine it was in crashed...  
(bad root disk) if I do this, will BadThings(tm) occur??

If so, can I just hack mdadm to fixup the order while reading the  
superblock, and recreate in degraded based on that?

Thanks again for the help.

- -Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCti/xN/nDplnlBBgRAuKIAKCNqiuC6+0NBUCQMFDxW7gMTnk8/ACfdHQ2
hSmINmk+Hq0v1QdZ+4teLRc=
=eBtc
-----END PGP SIGNATURE-----

Re: raid5 endian question....

[Neil Brown]

On Sunday June 19, aaron@blight.com wrote:
> Hello,
> 
> I'm attempting to move a raid5 array from a big endian ppc machine to  
> a little endian x86.
> Upon trying to import the array, I get:
> mdadm: No super block found on /dev/hde1 (Expected magic a92b4efc,  
> got fc4e2ba9)
> 
> I assume this to be an endianess issue...
> Is this a bug? Is just the magic number whacked? or are the  
> superblock data structures too?
> 
> what's the best way to fix this?

As has been said, the original raid superblock (still the default)
uses host-endian data and so cannot be moved between machines.
The new version uses little-endian, but isn't in wide use yet.

It would not be too hard to get mdadm to re-write the superblocks when
assembling an array on a different machine.  However I am not in a
position to test it very well.

If you would be willing to help test some changes over the next
several days, I'd be happy to add this functionality to mdadm.
The risk of data-loss for you would be very remote.  However there
would be some risk of extended down-time while you wait for me to fix
some silly bug.

The change would involve:
  1/ Teaching "mdadm --examine" to recognise a wrong-endian superblock
     and display it with suitable swaps.
  2/ Teaching "mdadm --assemble" to accept "--update=endian" which
     would byte-swap all the superblocks and write them out again.

NeilBrown