All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adam Goryachev <mailinglists@websitemanagers.com.au>
To: Andreas Klauer <Andreas.Klauer@metamorpher.de>
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 10:48:19 +1100	[thread overview]
Message-ID: <56F08843.4030909@websitemanagers.com.au> (raw)
In-Reply-To: <20160321231533.GB16913@EIS>

On 22/03/16 10:15, Andreas Klauer wrote:
> 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.

All of that is true, but it is a LUKS (encrypted) partition, so even if 
the filesystem format was simple, you wouldn't be able to work it out 
because all the data is encrypted. (At least, that is the point of data 
encryption right.... in practice maybe there are still some options, but 
I'm definitely out of my depth there).

Regards,
Adam

-- 
Adam Goryachev Website Managers www.websitemanagers.com.au

  reply	other threads:[~2016-03-21 23:48 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
2016-03-21 23:48                 ` Adam Goryachev [this message]
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=56F08843.4030909@websitemanagers.com.au \
    --to=mailinglists@websitemanagers.com.au \
    --cc=Andreas.Klauer@metamorpher.de \
    --cc=Killing-Time@gmx.de \
    --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 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.