Linux RAID subsystem development
 help / color / mirror / Atom feed
From: "Vanhorn, Mike" <michael.vanhorn@wright.edu>
To: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Odd --examine output
Date: Thu, 11 Apr 2013 20:31:08 +0000	[thread overview]
Message-ID: <CD8C946E.4111D%michael.vanhorn@wright.edu> (raw)
In-Reply-To: <CD8C2921.40FB6%michael.vanhorn@wright.edu>


>Why doesn't it instead give the same sort of metadata that the other disks
>show? It's as if there is no raid superblock on these two disks, but how
>is this possible if the disks have been part of a working array?

Update: by chance, I discovered that if I

 mdadm -e /dev/sdg1

then I get the output of the superblock. That is, the superblock is found
on the partition (apparently) but not on the disk device. This also works
for disk sdh, for which I couldn't find a superblock, either. However, for
the rest of the disks from the array (sd[cdefi]), there is no such device
as "sdc1", for example.

I have also discovered that for the drives where mdadm -e /dev/sdc (just
the disk) works, the version of the metadata is 0.90.00, where as those
other two where the superblock is on the partition (i.e. sdg1), the
version is 1.2. This makes more sense, since I create the array originally
(back in December) with the following command:

 mdadm --create --verbose /dev/md0 --metadata=1.2 --level=6
--raid-devices=7 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1
/dev/sdh1 /dev/sdi1 --spare-devices=1 /dev/sdj1


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.

---
Mike VanHorn
Senior Computer Systems Administrator
College of Engineering and Computer Science
Wright State University
265 Russ Engineering Center
937-775-5157
michael.vanhorn@wright.edu
http://www.cecs.wright.edu/~mvanhorn/





  reply	other threads:[~2013-04-11 20:31 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 [this message]
2013-04-11 21:15   ` Phil Turmel
     [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=CD8C946E.4111D%michael.vanhorn@wright.edu \
    --to=michael.vanhorn@wright.edu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox