From: "L.M.J" <linuxmasterjedi@free.fr>
To: Scott D'Vileskis <sdvileskis@gmail.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: Corrupted ext4 filesystem after mdadm manipulation error
Date: Fri, 25 Apr 2014 07:13:40 +0200 [thread overview]
Message-ID: <20140425071340.1ac35ded@netstation> (raw)
In-Reply-To: <CAK_KU4YUejncX9yQk4HM5HE=1-qPPxOibuRauFheo3jaBc8SaQ@mail.gmail.com>
Le Thu, 24 Apr 2014 16:22:49 -0400,
"Scott D'Vileskis" <sdvileskis@gmail.com> a écrit :
> I have been replying directly to you, not to the mailing list, since your
> case seems to be a case of user-screwed-up-his-own-data, and not a problem
> with mdadm/linux raid, nor a problem that will necessarily help someone
> else (since it is not likely someone will create a mess in exactly the same
> manner you have) .
Ha OK.
> To summarize:
> 1) You lost a disk. Even down a disk, you should have been able to
> run/start the array (in degraded mode) with only 2 disks, mounted the
> filesystem, etc.
Yes of course, it worked only with 2 disks the last 3 weeks.
> 2) You then should have simply partitioned and then --add 'ed the new disk.
> mdadm would have written a superblock to the new disk, and resynced the
> data
>
> I assume your original disks were in the order sdb, sdc, sdd.
Exactly
> Unfortunately, you might have clobbered your drives by recreating the
> array. You certainly clobbered your superblocks and changed the order when
> you did this:
> > ~# mdadm -Cv /dev/md0 --assume-clean --level=5 --raid-devices=3 /dev/sdc1
> /dev/sdd1 /dev/sdb1
>
> You changed the order, but because of the assume-clean, it shouldn't have
> started a resync of the data. Your file system probably had a fit though.
>
> Hindsight is 20/20, a mistake was made, it happens to all of us at some
> point or another, (I've lost arrays and filesystems with careless use of
> 'dd' once upon a time, once I was giving a raid demo to a friend with loop
> devices, mistyped something, and blew something away)
>
> IMPORTANT: At any point did your drives do a resync?
Unfortunatly : yes, resync occurs when I
> Assuming no, and assuming you haven't done any other writing to your
> disks(besides rewriting the superblocks), you can probably correct the
> order of your drives by reissuing the --create command with the two
> original drives, in the proper order, and the missing drive as the
> placeholder. (This will rewrite the superblocks again, but hopefully in the
> right order)
> mdadm -Cv /dev/md0 --level=5 --raid-devices=3 missing /dev/sdc1 /dev/sdd1
>
> If you can start that array (it will be degraded with only 2/3 drives) you
> should be able to mount and recover your data. You may need to run a full
> fsck again since your last fsck probably made a mess.
I shutdown the computer, remove the old disk, added the new one. Maybe I've messed up with SATA cables too.
Unfortunately, I use to start the degraded array like this :
~# mdadm --assemble --force /dev/sdc1 /dev/sdd1
didn't work
I created a partition on sdb, and then, the mistake
~# mdadm --stop /dev/md0
~# mdadm -Cv /dev/md0 --assume-clean --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
Didn't work better, then
~# mdadm --stop /dev/md0
~# mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/sdc1 /dev/sdd1 missing
~# mdadm --manage /dev/md0 --add /dev/sdb1
Looks even worst, isn't it ?
>
> Assuming you can mount and copy your data, you can then --add your 'new'
> drive to the array with the --add argument. (Note, you'll have to clear
> it's superblock or mdadm will object)
>
And what do you think of files fsck may recovered :
5,5M 2013-04-24 17:53 #4456582
5,7M 2013-04-24 17:53 #4456589
16M 2013-04-24 17:53 #4456590
25M 2013-04-24 17:53 #4456594
17M 2013-04-24 17:53 #4456578
18M 2013-04-24 17:53 #4456580
1,3M 2013-04-24 17:54 #4456597
1,1M 2013-04-24 17:54 #4456596
17M 2013-04-24 17:54 #4456595
2,1M 2013-04-24 17:54 #4456599
932K 2013-04-24 17:54 #4456598
Well, what should I do now ? mkfs everything and restart from scratch ?
--
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
next prev parent reply other threads:[~2014-04-25 5:13 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 ` Why would a recreation cause a different number of blocks?? Jeff Wiegley
2014-04-25 3:34 ` 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 ` L.M.J [this message]
2014-04-25 6:04 ` Corrupted ext4 filesystem after mdadm manipulation error 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=20140425071340.1ac35ded@netstation \
--to=linuxmasterjedi@free.fr \
--cc=linux-raid@vger.kernel.org \
--cc=sdvileskis@gmail.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).