From: Andreas Klauer <Andreas.Klauer@metamorpher.de>
To: Adam Goryachev <mailinglists@websitemanagers.com.au>
Cc: Patrick Tschackert <Killing-Time@gmx.de>,
lists@colorremedies.com, linux-raid@vger.kernel.org
Subject: Re: problems with dm-raid 6
Date: Tue, 22 Mar 2016 00:15:33 +0100 [thread overview]
Message-ID: <20160321231533.GB16913@EIS> (raw)
In-Reply-To: <56F07BBE.1010306@websitemanagers.com.au>
On Tue, Mar 22, 2016 at 09:54:54AM +1100, Adam Goryachev wrote:
> To my untrained eye, it looks like maybe the "first" drive in your array is correct, and
> hence the first block returns the correct data so you can access the
> LUKS, but the second (or third, or fourth) is damaged, and thats why you
> can't read the filesystem inside the LUKS.
This is a "problem" you get with arrays of many disks, if you "forget"
the correct drive order and then "create" the RAID anew, it might
result in a perfectly mountable filesystem but with errors down the
way since the first "wrong" data may appear outside the filesystems
immediate metadata zone, if two later disks switched places.
However the OP only uses 64K chunksize, so that gives a lot less
valid data than you'd get with 512K chunks. The LUKS header is already
larger than 64K so if there is really bad data on one of the disks
throughout, it's already quite lucky for the LUKS header to have
survived. May be a good idea to grab a backup of that header while
it's still working anyhow.
The one disk full of bad data theory might not even be correct,
maybe a sync started, and somehow the disk got accepted as fully
synced even though it didn't... because the controller silently
ignored all writes? Mysterious selective hardware failure?
> Once you can do that, then either the filesystem will "Just Work" or
> else you might need to do a repair depending on what exactly went wrong,
> and how much was written during that time.
Hope dies last.
If btrfs stored data the same way a traditional filesystem would,
uncompressed unencrypted unfragmented, you could hunt the raw data
of your md for magic headers of known large files and see if you
can tell in more detail the type of damage.
For example if you could find a large megapixel JPEG image like
that and were able to load it but it would appear corrupted at
some point, the point of corruption might point you to the
disk you no longer want to be in your array.
But I don't know enough/anything about btrfs so not sure if viable.
Regards,
Andreas Klauer
next prev parent reply other threads:[~2016-03-21 23:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <trinity-235b76ed-571d-4615-b6f7-b4d5ed6a116d-1458509365312@3capp-gmx-bs09>
2016-03-20 21:44 ` problems with dm-raid 6 Patrick Tschackert
2016-03-20 22:37 ` Andreas Klauer
2016-03-21 12:42 ` Phil Turmel
2016-03-21 13:27 ` Andreas Klauer
2016-03-21 21:26 ` Chris Murphy
2016-03-21 21:38 ` Andreas Klauer
2016-03-21 21:46 ` Chris Murphy
2016-03-21 22:42 ` Patrick Tschackert
2016-03-21 22:54 ` Adam Goryachev
2016-03-21 23:15 ` Andreas Klauer [this message]
2016-03-21 23:48 ` Adam Goryachev
2016-03-21 23:04 ` Andreas Klauer
2016-03-22 3:53 ` Chris Murphy
2016-03-22 4:22 ` Chris Murphy
2016-03-21 22:06 Patrick Tschackert
-- strict thread matches above, loose matches on Subject: below --
2016-03-21 22:19 Patrick Tschackert
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=20160321231533.GB16913@EIS \
--to=andreas.klauer@metamorpher.de \
--cc=Killing-Time@gmx.de \
--cc=linux-raid@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=mailinglists@websitemanagers.com.au \
/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).