Re: Big Endian RAID discovery problem (metadata 1!)

[Rolf Eike Beer <eike-kernel@sf-tec.de>]

Am 2017-06-29 23:54, schrieb Shaohua Li:
> On Wed, Jun 28, 2017 at 10:14:21PM +0200, Rolf Eike Beer wrote:
>> Am Mittwoch, 28. Juni 2017, 13:55:09 schrieb Adam Thompson:
>> > If you search the archives, I had a very similar problem a few months ago.
>> > There is already an option to mdadm to update a v1 superblock in the wrong
>> > byte order.  It just wasn't obvious when looking at the mdadm man page.
>> > Going from memory, search for "byte order" instead of "endian" to find the
>> > option. -Adam
>> 
>> If you refer to --update=byteorder, the documentation says it is only 
>> for
>> v0.90 metadata. Also it's only the super_offset field so far, other 
>> fields like
>> magic are correct.
> 
> There are patches in this side to correctly handle endian:
> 
> 1345921393ba md: fix incorrect use of lexx_to_cpu in 
> does_sb_need_changing
> 3fb632e40d76 md: fix super_offset endianness in 
> super_1_rdev_size_change
> 
> probably we should make these into -stable tree, but I never got 
> reports on
> this side. can you try?

That likely is the problem, it was kernel 4.10.2 that was used when the 
array was expanded. Yes, this should really get backported. And 
something like "byteorder2" for mdadm to make it easier for people with 
such arrays to fix that would be awesome.

After changing the sb_offset and csum fields (and UUID, to avoid bad 
resync from the old member on sda2) and writing the sectors back my 
array now works again.

Eike