From: Jeff Wiegley <jeffw@csun.edu>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Why would a recreation cause a different number of blocks??
Date: Thu, 24 Apr 2014 15:25:45 -0700 [thread overview]
Message-ID: <53598F69.5070700@csun.edu> (raw)
In-Reply-To: <CAK_KU4ZDi7qUNKft7+GH8mLcKG0yq1KBg6hn1DV9jgc=BN02tw@mail.gmail.com>
Still trying to restore my large storage system with out
total screwing up. There are two different raid md devices.
both had their superblocks wiped and one of the six drives
is screwed (the other 5 are fine).
Before the human failure: (OS reinstall and I only deleted
the MD devices in the ubuntu installer. I think this just
zeros the md superblocks of the affected partitions)
Personalities : [raid6] [raid5] [raid4] [raid1] [linear] [multipath]
[raid0] [raid10]
md3 : active raid6 sda1[0] sdc1[2] sde1[4] sdb1[1] sdd1[6]
1073735680 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/5]
[UUUUU_]
I recreated the device with:
mdadm --create --assume-clean --level=6 --raid-devices=6 /dev/md0
/dev/sdd1 /dev/sdb1 /dev/sde1 /dev/sdc1 /dev/sda1 missing
and now it reports:
root@nas:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sda1[4] sdc1[3] sde1[2] sdb1[1] sdd1[0]
1073215488 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/5]
[UUUUU_]
Why did my block counts change? The disk partitions weren't touched
or changed at any point. Shouldn't I have gotten the same size?
The created device isn't work. There is suppose to be luks encrypted
volume there but luksOpen reports there is no luks header. (and there
use to be). Would the odd change in size indicate total corruption?
- Jeff
next prev parent reply other threads:[~2014-04-24 22:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-24 5:05 Corrupted ext4 filesystem after mdadm manipulation error L.M.J
2014-04-24 17:48 ` L.M.J
[not found] ` <CAK_KU4a+Ep7=F=NSbb-hqN6Rvayx4QPWm-M2403OHn5-LVaNZw@mail.gmail.com>
2014-04-24 18:35 ` L.M.J
[not found] ` <CAK_KU4Zh-azXEEzW4f1m=boCZDKevqaSHxW0XoAgRdrCbm2PkA@mail.gmail.com>
2014-04-24 19:53 ` L.M.J
[not found] ` <CAK_KU4aDDaUSGgcGBwCeO+yE0Qa_pUmMdAHMu7pqO7dqEEC71g@mail.gmail.com>
2014-04-24 19:56 ` L.M.J
2014-04-24 20:31 ` Scott D'Vileskis
2014-04-24 22:25 ` Jeff Wiegley [this message]
2014-04-25 3:34 ` Why would a recreation cause a different number of blocks?? Mikael Abrahamsson
2014-04-25 5:02 ` Jeff Wiegley
2014-04-25 6:01 ` Mikael Abrahamsson
2014-04-25 6:45 ` Jeff Wiegley
2014-04-25 7:25 ` Mikael Abrahamsson
2014-04-25 7:05 ` Jeff Wiegley
[not found] ` <CAK_KU4YUejncX9yQk4HM5HE=1-qPPxOibuRauFheo3jaBc8SaQ@mail.gmail.com>
2014-04-25 5:13 ` Corrupted ext4 filesystem after mdadm manipulation error L.M.J
2014-04-25 6:04 ` Mikael Abrahamsson
2014-04-25 11:43 ` L. M. J
2014-04-25 13:36 ` Scott D'Vileskis
2014-04-25 14:43 ` L.M.J
2014-04-25 18:37 ` Is disk order relative or are the numbers absolute? Jeff Wiegley
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=53598F69.5070700@csun.edu \
--to=jeffw@csun.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;
as well as URLs for NNTP newsgroup(s).