All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Alfred Matthews <asm13243546@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: on assembly and recovery of a hardware RAID
Date: Mon, 20 Mar 2017 16:34:09 +1100	[thread overview]
Message-ID: <87lgs0cy0e.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <CAAZLhTcoU232uBs2zcK6TFj67Jru5oeNE_F0T2fQR6Un66OPXA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

On Sat, Mar 18 2017, Alfred Matthews wrote:

> I've switched to the backup drives which are clones of the first, now,
> so destructive operations are ok if necessary. Also signatures will
> have changed.
>
> 0. Hm. Evidently the system is JHFS instead of HFS+, per the output
> below. Unsure if there is separate tooling in Debian.
>
> 1. Mount via
>
> mdadm --build /dev/md0 --level=0 -n2 --chunk=512K /dev/sdc2 /dev/sdb2
>
> works just fine. Thanks!
>
> 2. I'm still sticking with the non-destructive, non-mount edits for
> now. So I can report the following:
>
> hpfsck -v /dev/md0 | cat >> hpfsck_output.txt
>
> yields some stuff probably more enlightening than prior.

This is promising until:


> *** Checking Backup Volume Header:
> Unexpected Volume signature '  ' expected 'H+'

Here the backup volume header, which is 2 blocks (blocks are 8K) from
the end of the device, looks wrong.
This probably means the chunk size is wrong.
I would suggest trying different chunksizes, starting at 4K and
doubling, until this message goes away.
That still might not be the correct chunk size, so I would continue up
to several megabytes and find all the chunksizes that seem to work.
Then look at what else hpfsck says on those.

BTW, this:
> Invalid total blocks 2BA8CC68, expected 0 Done ***
is not a real problem, just some odd code.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2017-03-20  5:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-10 20:37 on assembly and recovery of a hardware RAID Alfred Matthews
2017-03-13 21:32 ` NeilBrown
2017-03-14 17:27   ` Alfred Matthews
2017-03-15  2:56     ` NeilBrown
2017-03-18 17:11       ` Alfred Matthews
2017-03-18 18:08         ` Alfred Matthews
2017-03-20  5:34           ` NeilBrown [this message]
2017-03-20 21:42             ` Alfred Matthews
2017-03-21  2:38               ` NeilBrown
2017-03-21 12:09                 ` Alfred Matthews
2017-05-03 15:44                   ` Alfred Matthews
2017-05-11 17:18                     ` Alfred Matthews
2017-05-11 22:27                     ` NeilBrown
2017-05-12 15:57                       ` Alfred Matthews

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=87lgs0cy0e.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=asm13243546@gmail.com \
    --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.