linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Hardcastle <jonathan.hardcastle@gmail.com>
To: Leslie Rhorer <lrhorer@satx.rr.com>
Cc: Phil Turmel <philip@turmel.org>, linux-raid@vger.kernel.org
Subject: Re: argh!
Date: Sun, 31 Oct 2010 21:18:52 +0000	[thread overview]
Message-ID: <AANLkTimL=Z5gh+cbadd5+k66AoNZ8xc9upMbfE_Yqxac@mail.gmail.com> (raw)
In-Reply-To: <C4.61.07087.9F0BCCC4@cdptpa-omtalb.mail.rr.com>

On 31 October 2010 00:57, Leslie Rhorer <lrhorer@satx.rr.com> wrote:
>> >> > a new HDD has failed on me during a scrub.... i tried to remove/fail
>> it
>> >> but
>> >> > it kept saying the device was busy. so i forced a reboot.
>
>        BTW, it's better, if you can, to free up the device, rather than
> reboot.  Now that you have rebooted, that's no longer possible.
>
>> >> > I have physically disconnected the drive..
>> >> >
>> >> > can anyone take alook at the examine below and tell me if it is
>> should
>> >> > assemble ok?
>> >> >
>> >> > I tried
>> >> >
>> >> > mdadm --assemble /dev/md4 /dev/sda1 /dev/sdb1 /dev/sdd1 /dev/sde1
>> >> /dev/sdf1
>> >> > /dev/sdg1
>> >>
>> >> I'd try:
>> >>
>> >> mdadm --assemble /dev/md4 /dev/sd{g,a,e}1 missing /dev/sd{d,b,f}1
>> >
>> >
>> >        Yeah, I would, too.  Also, what are the contents of
>> > /etc/mdadm/mdadm.conf?  If it is correct, then `mdadm --assemble --scan`
>> > should work.
>> >
>> >
>>
>> Hey, yeah I am confused as drives have failed before and it has still
>> assembled. I think it is because it is unclean....
>>
>> Can I ask how did you arrive at the command list?
>
>        Look at the results of --examine.  Every one shows the list of
> drives and their order.
>
>> what is wrong with dbf?
>
>        'No idea.  SMART might give you an idea, or the kernel logs.
>
>> also this is my mdadm.conf
>>
>>
>> DEVICE /dev/sd[abcdefg]1 /dev/hd[ab]1
>>
>> ARRAY /dev/md/4 metadata=0.90 UUID=7438efd1:9e6ca2b5:d6b88274:7003b1d3
>> ARRAY /dev/md/3 metadata=0.90 UUID=a1f24bc9:4e72a820:3a03f7dc:07f9ab98
>> ARRAY /dev/md/2 metadata=0.90 UUID=0642323a:938992ef:b750ab21:e5a55662
>> ARRAY /dev/md/1 metadata=0.90 UUID=d4eeec62:148b3425:3f5e931c:bb3ef499
>
>        --scan may work.  I suggest updating the file with all the array
> members.  Why are all the arrays assembled with 0.90 superblocks?  The 0.90
> superblock has some significant limitations.  They may not be causing you
> grief right now, but they could in the future.  The only arrays I have built
> with 0.90 superblocks are the /boot targets, because GRUB2 does not support
> 1.x superblocks.  I've chosen 1.2 for all the others.
>

Hi,

Thanks for your help. I use 0.90 as that is what there was when the
machine was build ~3yrs ago.. the array has been grown and resized
since then.

Does anyone have a feature list for the superblocks? Why upgrade.....?

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-10-31 21:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-30 11:56 argh! Jon Hardcastle
2010-10-30 15:45 ` argh! Phil Turmel
2010-10-30 21:10   ` argh! Leslie Rhorer
2010-10-30 21:52     ` argh! Jon Hardcastle
2010-10-30 21:54       ` argh! Jon Hardcastle
2010-10-30 22:01         ` argh! Jon Hardcastle
2010-10-31  0:07           ` argh! Leslie Rhorer
2010-10-31 18:52             ` argh! Jon Hardcastle
2010-10-31 19:43               ` argh! Neil Brown
2010-10-31 19:54                 ` argh! Jon Hardcastle
2010-11-01 21:39               ` argh! Leslie Rhorer
2010-10-31  0:05         ` argh! Leslie Rhorer
2010-10-30 23:57       ` argh! Leslie Rhorer
2010-10-31 21:18         ` Jon Hardcastle [this message]
2010-10-31 21:44           ` argh! Neil Brown
2010-11-01  1:51             ` argh! John Robinson

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='AANLkTimL=Z5gh+cbadd5+k66AoNZ8xc9upMbfE_Yqxac@mail.gmail.com' \
    --to=jonathan.hardcastle@gmail.com \
    --cc=Jon@eHardcastle.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=lrhorer@satx.rr.com \
    --cc=philip@turmel.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;
as well as URLs for NNTP newsgroup(s).