From: Mathias Mueller <raidfail@gmx.de>
To: Phil Turmel <philip@turmel.org>
Cc: Linux raid <linux-raid@vger.kernel.org>,
linux-raid-owner@vger.kernel.org
Subject: Re: broken raid level 5 array caused by user error
Date: Mon, 18 Jan 2016 16:33:00 +0100 [thread overview]
Message-ID: <44d28ec402622b25c4d4d7a32a8888d9@pingofdeath.de> (raw)
In-Reply-To: <a7d58e8e4c319c320bc531b8d2bf11e7@pingofdeath.de>
Hi Phil,
first thanks a lot for all your help and time you already spent on me
and my problem. I gathered some more information and hope you can help
me a bit more.
I found this on serverfault.com and tried to figure out my raid layout
using some image file that is stored on my raid for sure:
http://serverfault.com/questions/347606/recover-raid-5-data-after-created-new-array-instead-of-re-using
this is my current device mapping:
JK1100YAG64A1T -> sdc
ML0220F30PZUVD -> sdd (this is the disk I added last)
JK1121YAG7YDLS -> sde
JK1170YBHYV6MD -> sdf
First I tried to figure out the chunk size. I used a jpg file that was
stored on the raid for sure and read 8x32 Bytes with an offset of 64k
from that file. Than I used bgrep to search for the bytestrings on my
physical devices. I found five sequent byte strings on one physical
device, so I think the chunk sice must be bigger than 256k.
Because I was pretty sure, that my chunk size is 512k, I was reading
5x32Byte with an offset of 512k from my jpg file, to determine the order
of the devices. After bgrep was done, I got the following results:
- Every bytestring was found 3x on my physical devices, I think it's
because the file is existing 3x in different folders on my raid device
(which is pretty certain, I know that the file is existing 2x at least)
- sdd1 seems to have a different offset as the other physical devices,
it's the disk I added last after switching from debian to centos some
years ago
- the following tables show at which offsets and on which physical
devices the five byte strings have been found:
offset sdc1 sdd1 sde1 sdf1
---------------------------------------------------
5400bd3000 2
5400cc3000 3 1
5400d43000 4 5
offset sdc1 sdd1 sde1 sdf1
---------------------------------------------------
87b4e52000 3
87b4f42000 1 2
87b4fc2000 5 4
offset sdc1 sdd1 sde1 sdf1
---------------------------------------------------
cb2d87f000 2
cb2d96f000 1
cb2d9ef000 4 3 5
So I think using the last table is the easiest one to figure out the
partition order and the data offset between sdd1 and the other devices?
offset sdc1 sdd1 sde1 sdf1
---------------------------------------------------
cb2d96f000 (2) P 1
cb2d9ef000 4 P 3 5
If I am right, it would mean, that the order of my physical devices is
sdf1 sdd1 sde1 sdc1 (without knowing which one is the first partition)
and the offset between sdd1 and the other devices is f0000. Are my
assumptions correct? How can I go on with this information?
Thanks a lot in advance
Best regards
Mathias
next prev parent reply other threads:[~2016-01-18 15:33 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-10 21:33 broken raid level 5 array caused by user error Mathias Mueller
2015-11-10 21:41 ` Phil Turmel
2015-11-10 23:47 ` Mathias Mueller
2015-11-10 23:59 ` Phil Turmel
[not found] ` <b0cdddd4394bbc1356980bb61ac199c3@pingofdeath.de>
2015-11-11 1:00 ` Phil Turmel
2015-11-11 17:53 ` Mathias Mueller
2016-01-18 15:33 ` Mathias Mueller [this message]
2016-01-18 19:09 ` Phil Turmel
2016-01-19 14:35 ` Mathias Mueller
2016-01-19 17:51 ` Phil Turmel
2016-01-19 19:37 ` Phil Turmel
2016-01-20 9:04 ` Mathias Mueller
2016-01-22 9:30 ` Mathias Mueller
2016-01-22 17:16 ` Phil Turmel
2016-01-22 17:39 ` Mathias Mueller
2016-01-22 19:13 ` Phil Turmel
2016-01-25 10:02 ` Mathias Mueller
2015-11-11 1:03 ` Phil Turmel
2015-11-11 1:29 ` Mathias Mueller
-- strict thread matches above, loose matches on Subject: below --
2015-11-09 11:27 Mathias Mueller
2015-11-09 11:56 ` Mikael Abrahamsson
2015-11-09 13:50 ` Phil Turmel
[not found] ` <07de4cd96f39ecb6154794d072ca12e7@pingofdeath.de>
[not found] ` <5640B8AD.3030800@turmel.org>
2015-11-09 15:41 ` Mathias Mueller
[not found] ` <d764bf541381927fa4183c9266fb3f5a@pingofdeath.de>
[not found] ` <5640C38B.4060503@turmel.org>
[not found] ` <a3a91665c4b7cdd70dacc7d8815cc365@pingofdeath.de>
2015-11-09 21:13 ` Phil Turmel
2015-11-10 8:37 ` Mathias Mueller
2015-11-10 13:55 ` Phil Turmel
2015-11-10 14:55 ` Mathias Mueller
2015-11-10 15:20 ` Mathias Mueller
2015-11-10 15:28 ` Phil Turmel
2015-11-10 21:02 ` Mathias Mueller
2015-11-10 21:11 ` 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=44d28ec402622b25c4d4d7a32a8888d9@pingofdeath.de \
--to=raidfail@gmx.de \
--cc=linux-raid-owner@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=philip@turmel.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.