Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Phil Turmel <philip@turmel.org>
To: "Vanhorn, Mike" <michael.vanhorn@wright.edu>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Odd --examine output
Date: Thu, 11 Apr 2013 17:15:37 -0400	[thread overview]
Message-ID: <516727F9.9020008@turmel.org> (raw)
In-Reply-To: <CD8C946E.4111D%michael.vanhorn@wright.edu>

On 04/11/2013 04:31 PM, Vanhorn, Mike wrote:

> So, if I created the array using version 1.2 of the metadata and the
> devices specified are sd[cdefghij]1, then why am I not able to see that
> metadata now?
> 
> I am really confused.

Version 0.90 metadata, which lives at the end of the disk or partition,
doesn't include a length or other piece of partition geometry that
clearly identifies the beginning of the array.  So v0.90 metadata that
belongs to the last partition of a disk can be mistaken for metadata
belonging to that whole disk, and vice versa.

v1.x metadata has more device info, so this can't happen to v1.0
metadata, even though it is at the end of the device as well.  v1.1 and
v1.2 metadata are at the beginning, therefore won't be found with the
wrong starting sector.

I suspect what happened to your system:

1) Old array running w/ v0.90 metadata on /dev/sd[]1 is taken out of
service.
2) New array w/ v1.2 metdata is created, but for some reason, the v0.90
metadata doesn't get destroyed.
3) Partition tables on certain disks are wiped, hiding the v1.2 metadata.

I'm not sure if any particular version of mdadm would do #2, but it is
plausible.

#3 is quite concerning, as it suggest the presence of a rogue program
with admin rights, or a rogue administrator, or a *really* questionable
device driver.

Anyways, if you copy the partition table from a properly working drive
to one of the oddballs, it might expose the original partition data,
including the v1.2 metadata.  (Although, you seem to have partitions
starting at sector 63--a real performance killer for modern drives.)

There's other data I suggested you collect in my response to your
original inquiry.  There'd be much less guesswork in my replies if you
supplied it.

Phil

  reply	other threads:[~2013-04-11 21:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-11 12:47 Odd --examine output Vanhorn, Mike
2013-04-11 20:31 ` Vanhorn, Mike
2013-04-11 21:15   ` Phil Turmel [this message]
     [not found] <51681FB2.8060803@turmel.org>
2013-04-12 16:47 ` Vanhorn, Mike
2013-04-12 17:21   ` Phil Turmel
2013-04-15 13:46 ` Vanhorn, Mike
2013-04-15 14:00   ` Phil Turmel
2013-04-15 18:42   ` Roy Sigurd Karlsbakk
2013-04-15 20:13     ` John Stoffel
2013-04-15 16:06       ` Oliver Schinagl
2013-04-16  8:58       ` Robin Hill
2013-04-18 11:33         ` Roy Sigurd Karlsbakk
2013-04-18 13:03           ` John Stoffel
2013-04-18 14:22             ` Roy Sigurd Karlsbakk
2013-04-18 11:37         ` Roy Sigurd Karlsbakk
2013-04-18  6:32     ` Sam Bingner

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=516727F9.9020008@turmel.org \
    --to=philip@turmel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=michael.vanhorn@wright.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox