All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Turmel <philip@turmel.org>
To: Dave Gomboc <dave_gomboc@acm.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: raid10 recovery assistance requested
Date: Mon, 23 Sep 2013 00:12:26 -0400	[thread overview]
Message-ID: <523FBFAA.3050705@turmel.org> (raw)
In-Reply-To: <CA+dwz-2qqYbL1uFmL+vnS=ht6ZHxMDkRRBUYPz0KFQZNZkeK-A@mail.gmail.com>

On 09/23/2013 12:04 AM, Dave Gomboc wrote:
>> Ok.  I can't determine how the superblocks ended up the way they did,
>> but the first two chunks appear to follow the proper patterns.
>>
>> I think you're best bet is to disconnect two of the drives, leaving one
>> that identifies as "0" and one that identifies as "3".
> 
> root@sysresccd /root % ls -l /dev/disk/by-id | grep Hitachi | grep -v part1
> lrwxrwxrwx 1 root root  9 Sep 22 20:17
> ata-Hitachi_HDS724040ALE640_PK1310PAG5ZY0J -> ../../sdb
> lrwxrwxrwx 1 root root  9 Sep 22 20:17
> ata-Hitachi_HDS724040ALE640_PK1310PAG62REJ -> ../../sdc
> lrwxrwxrwx 1 root root  9 Sep 22 20:17
> ata-Hitachi_HDS724040ALE640_PK1310PAG62T2J -> ../../sdd
> lrwxrwxrwx 1 root root  9 Sep 22 20:17
> ata-Hitachi_HDS724040ALE640_PK1311PAG4W5TS -> ../../sda
> root@sysresccd /root % cat /proc/mdstat
> Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]
> [raid4] [raid10]
> md127 : inactive sdd1[3](S) sda1[0](S)
>       3907021954 blocks super 1.2
> 
> unused devices: <none>
> 
> Should I be disconnecting sdb and sdc, disconnecting sda and sdd, or
> does it matter?

Actually, from that report, just do "mdadm /dev/md127 --run".

> I should reboot using the rescue disk before attempting the forced
> assembly, not my boot drive, right?

Yes, but only necessary if the above fails.  And if there's a partial
assembly, you might need to use "mdadm --stop".

> Sorry if the answers to these questions seem obvious to you: I want to
> make sure that I understand you exactly.  I am moderately terrified at
> the moment.

You have duplicated the disks.  You have all of the insurance possible.

>> Then use "mdadm -Af /dev/mdX /dev/sdY1 /dev/sdZ1"
>>
>> The "-f" will force the assembly without regard to the event counts.
>> Then you can take a backup.  Finally you can add devices as "new" ones
>> to rebuild back to full redundancy.  (Fix your timeouts before
>> attempting the latter.)
> 
> When following up on your advice to search for those other terms, I
> saw several examples where people specified 7 seconds to the disk
> drive using that control program, and also read somewhere that while
> Linux's software raid will wait, that Linux's scsi subsystem has a 30
> second timeout.  So, 7 seconds sounds good?

Most traditional enterprise drives power up with t=7 seconds.  The SSDs
I've used use t=4 seconds.

Keep in mind that the setting is forgotten when the drive powers down.
You need the commands in rc.local or your distro's equivalent.

Phil


  reply	other threads:[~2013-09-23  4:12 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-16  3:30 raid10 recovery assistance requested Dave Gomboc
2013-09-19  3:20 ` Dave Gomboc
2013-09-19  4:29   ` Stan Hoeppner
2013-09-20  5:29     ` Dave Gomboc
2013-09-22 17:15       ` Dave Gomboc
2013-09-22 21:52         ` Phil Turmel
2013-09-22 22:45           ` Dave Gomboc
2013-09-22 23:04             ` Dave Gomboc
2013-09-22 23:25             ` Phil Turmel
     [not found]               ` <CA+dwz-0eskPSQ44v0vgwfjwRpTbQaokQ3Q258Em1W2eRi1SO4w@mail.gmail.com>
2013-09-23  2:54                 ` Phil Turmel
2013-09-23  3:19                   ` Dave Gomboc
2013-09-23  3:27                     ` Phil Turmel
2013-09-23  3:34                       ` Dave Gomboc
2013-09-23  3:51                         ` Phil Turmel
2013-09-23  4:04                           ` Dave Gomboc
2013-09-23  4:12                             ` Phil Turmel [this message]
2013-09-23  4:55                               ` Dave Gomboc
2013-09-23  5:07                                 ` Dave Gomboc
2013-09-23  5:19                                 ` Adam Goryachev
2013-09-23 12:32                                 ` Phil Turmel
2013-09-23 12:57                                   ` Dave Gomboc
2013-09-24  0:29                                     ` Adam Goryachev
2013-09-24  5:55                                       ` Dave Gomboc
2013-09-28 15:47                                     ` Dave Gomboc
2013-09-28 16:01                                       ` Phil Turmel

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=523FBFAA.3050705@turmel.org \
    --to=philip@turmel.org \
    --cc=dave_gomboc@acm.org \
    --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.