All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Pittman <daniel@rimspace.net>
To: linux-raid@vger.kernel.org
Subject: Re: endianness of Linux kernel RAID
Date: Thu, 04 Aug 2005 17:20:35 +1000	[thread overview]
Message-ID: <87y87if9rw.fsf@rimspace.net> (raw)
In-Reply-To: 17137.47596.652834.79165@cse.unsw.edu.au

Neil Brown <neilb@cse.unsw.edu.au> writes:
> On Thursday August 4, neilb@cse.unsw.edu.au wrote:
>> 
>> Oopps....
>> I meant to send the following in reply to a recent message from
>> Gregory Seidman, but inadvertently send it in reply to an earlier
>> message from Aaron Botsis (which I must have missed..)
>> 
>> Still, the offer is open to either, or anyone else.
>
> I decided to try it anyway...
>
> The following patch, when applied to mdadm-2.0-devel-3 (Recently
> released) should allow:
>
>   mdadm --examine --metadata=0.swap /dev/sda1
>
> which will show the superblock with bytes swapped.  If that looks right for
> all devices, then
>
>   mdadm --assemble /dev/mdX --update=byteorder /dev/sda1 /dev/sdb1 ...
>
> will assemble the array after swapping the byte order on all devices.
> Once it has been assembled this way, the superblocks will have the
> correct byte order, and in future the array can be assembled in the
> normal way.
>
> Feedback would be very welcome.

If I read your notes correctly, it should be possible to determine that
this is (or isn't) a byte-swapped v0 superblock by checking for the
byte-swapped magic number, right?

In that case, I think it would be good to have --update=byteorder refuse
to work if that magic number check either wasn't the byte-swapped
variant.

Adding a 'force' or something to bypass the check if you *really* want
to seems reasonable-ish.

That would make it just that little bit harder to accidentally byte-swap
a superblock when you shouldn't have done so.

  Daniel



  reply	other threads:[~2005-08-04  7:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-03 12:07 endianness of Linux kernel RAID Gregory Seidman
2005-08-03 13:05 ` Paul Clements
2005-08-03 15:36   ` Gregory Seidman
2005-08-03 15:51     ` Paul Clements
2005-08-03 18:50 ` Dan Stromberg
2005-08-04  5:14 ` Neil Brown
2005-08-04  6:47   ` Neil Brown
2005-08-04  7:20     ` Daniel Pittman [this message]
2005-08-04 11:40   ` Gregory Seidman
  -- strict thread matches above, loose matches on Subject: below --
2005-08-09  4:49 Brent Walsh
2005-08-09  4:57 ` Neil Brown
2005-08-11 13:38   ` Brent Walsh
2005-08-18  4:44     ` Neil Brown
2005-08-01 17:42 Gregory Seidman
2005-08-01 18:18 ` Eugene Surovegin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y87if9rw.fsf@rimspace.net \
    --to=daniel@rimspace.net \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.