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
--
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
