linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: travis+ml-linux-raid@subspacefield.org
To: Chris Murphy <lists@colorremedies.com>
Cc: Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: bootsect replicated in p1, RAID enclosure suggestions?
Date: Thu, 1 Sep 2016 19:18:07 -0700	[thread overview]
Message-ID: <20160902021807.GS32250@subspacefield.org> (raw)
In-Reply-To: <CAJCQCtQLLJEoovBtks0ft9XArHwwZTMqBGobW5WavsQydbqSBQ@mail.gmail.com>

On Thu, Aug 25, 2016 at 10:25:35PM -0600, Chris Murphy wrote:
> Well that file does seem stale, because those partitions aren't
> actually part of LVM. They're members of an mdadm array. I don't know
> where LVM comes into this because we don't have the complete layout.

md127 = /dev/sd{b,c,d,e}1
LUKS on that
PV/VG/LV on that.

/dev/sda5 is also a LUKS partition with LVM on it for root.

I wonder if it's possible that whatever restored a GPT also restored a
LVM header, and somehow that picked it up?

Anyway, after doing bitwise backups of disks, I did a create
--assume-clean with --level=raid0 and the thing seems fine.

# fsck /dev/V_hostname/L_bu
fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
/dev/mapper/V_hostname-L_bu contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #67095 (65535, counted=0).
Fix<y>? yes

Free blocks count wrong (496207637, counted=496207638).
Fix<y>? yes

And that was pretty much it.
-- 
http://www.subspacefield.org/~travis/ | if spammer then john@subspacefield.org
"Computer crime, the glamor crime of the 1970s, will become in the
1980s one of the greatest sources of preventable business loss."
John M. Carroll, "Computer Security", first edition cover flap, 1977

  reply	other threads:[~2016-09-02  2:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23  5:09 bootsect replicated in p1, RAID enclosure suggestions? travis+ml-linux-raid
2016-08-24  2:14 ` travis+ml-linux-raid
2016-08-24 17:15 ` Chris Murphy
2016-08-25  6:25   ` travis+ml-linux-raid
2016-08-25 21:06     ` Wols Lists
2016-08-25 22:32     ` Chris Murphy
2016-08-26  2:33       ` Phil Turmel
2016-08-26  2:48         ` Chris Murphy
2016-08-26  3:11           ` travis+ml-linux-raid
2016-08-26  2:50       ` travis
2016-08-26  3:21         ` Chris Murphy
2016-08-26  3:58           ` travis
2016-08-26  4:06             ` travis+ml-linux-raid
2016-08-26  4:25               ` Chris Murphy
2016-09-02  2:18                 ` travis+ml-linux-raid [this message]
2016-09-01 17:22 ` Wols Lists
2016-09-01 23:10   ` Chris Murphy

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=20160902021807.GS32250@subspacefield.org \
    --to=travis+ml-linux-raid@subspacefield.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=lists@colorremedies.com \
    /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).