linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Another Sillyname <anothersname@googlemail.com>
To: Alireza Haghdoost <alireza@cs.umn.edu>,
	Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: Fwd: RAID6 Array crash during reshape.....now will not re-assemble.
Date: Fri, 4 Mar 2016 21:52:49 +0000	[thread overview]
Message-ID: <CAOS+5GEr2p9nOcxWJxnX_u3_2PGyTfEPXnnzWYsMBWuXxSy-4Q@mail.gmail.com> (raw)
In-Reply-To: <CAB-428nDwNOuFe5Bqh=LXD5Vw8MxzKzpP6ELuAqen1wD54urmA@mail.gmail.com>

I have no clue, they were used in a temporary system for 10 days about
8 months ago, they were then used in the new array that was built back
in August.

Even if the metadata was removed from those two drives the 'merge'
that happened, without warning or requiring verification, seems to now
have 'contaminated' all the drives possibly.

I'm still reasonably convinced the data is there and intact, just need
an analytical approach to how to recover it.



On 4 March 2016 at 21:02, Alireza Haghdoost <alireza@cs.umn.edu> wrote:
> On Fri, Mar 4, 2016 at 2:30 PM, Another Sillyname
> <anothersname@googlemail.com> wrote:
>> That's possibly true, however there are lessons to be learnt here even
>> if my array is not recoverable.
>>
>> I don't know the process order of doing a reshape....but I would
>> suspect it's something along the lines of.
>>
>> Examine existing array.
>> Confirm command can be run against existing array configuration (i.e.
>> It's a valid command for this array setup).
>> Do backup file (if specified)
>> Set reshape flag high
>> Start reshape
>>
>> I would suggest....
>>
>> There needs to be another step in the process
>>
>> Before 'Set reshape flag high' that the backup file needs to be
>> checked for consistency.
>>
>> My backup file appears to be just full of EOLs (now for all I know the
>> backup file actually gets 'created' during the process and therefore
>> starts out as EOLs).  But once the flag is set high you are then
>> committing the array before you know if the backup is good.
>>
>> Also
>>
>> The drives in this array had been working correctly for 6 months and
>> undergone a number of reboots.
>>
>> If, as we are theorising, there was some metadata from a previous
>> array setup on two of the drives that as a result of the reshape
>> somehow became the 'valid' metadata regarding those two drives RAID
>> status then I would suggest that during any mdadm raid create process
>> there is an extensive and thorough check of any drives being used to
>> identify and remove any possible previously existing RAID metadata
>> information...thus making the drives 'clean'.
>>
>>
>>
>>
>>
>>
>> On 4 March 2016 at 19:11, Alireza Haghdoost <alireza@cs.umn.edu> wrote:
>>> On Fri, Mar 4, 2016 at 1:01 PM, Another Sillyname
>>> <anothersname@googlemail.com> wrote:
>>>>
>>>>
>>>> Thanks for the suggestion but I'm still stuck and there is no bug
>>>> tracker on the mdadm git website so I have to wait here.
>>>>
>>>> Ho Huum
>>>>
>>>>
>>>
>>> Looks like it is going to be a long wait. I think you are waiting to
>>> do something that might not be inplace/available at all. That thing is
>>> the capability to reset reshape flag when the array metadata is not
>>> consistent. You had an old array in two of these drives and it seems
>>> mdadm confused when it observes the drives metadata are not
>>> consistent.
>>>
>>> Hope someone chip in some tricks to do so without a need to develop
>>> such a functionality in mdadm.
>
> Do you know the metadata version that is used on those two drives ?
> For example, if the version is < 1.0 then we could easily erase the
> old metadata since it has been recorded in the end of the drive. Newer
> metada versions after 1.0 are stored in the beginning of the drive.
>
> Therefore, there is no risk to erase your current array metadata !

  reply	other threads:[~2016-03-04 21:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-02  3:46 RAID6 Array crash during reshape.....now will not re-assemble Another Sillyname
2016-03-02 13:20 ` Wols Lists
     [not found]   ` <CAOS+5GHof=F94x58SKqFojV26hGpDSLF85dFfm8Xc6M43sN6jA@mail.gmail.com>
2016-03-02 13:42     ` Fwd: " Another Sillyname
2016-03-02 15:59       ` Another Sillyname
2016-03-03 11:37         ` Another Sillyname
2016-03-03 12:56           ` Wols Lists
     [not found]             ` <CAOS+5GH1Rcu8zGk1dQ+aSNmVzjo=irH65KfPuq1ZGruzqX_=vg@mail.gmail.com>
2016-03-03 14:07               ` Fwd: " Another Sillyname
2016-03-03 17:48                 ` Sarah Newman
2016-03-03 17:59                   ` Another Sillyname
2016-03-03 20:47                     ` John Stoffel
2016-03-03 22:19                       ` Another Sillyname
2016-03-03 22:42                         ` John Stoffel
2016-03-04 19:01                           ` Another Sillyname
2016-03-04 19:11                             ` Alireza Haghdoost
2016-03-04 20:30                               ` Another Sillyname
2016-03-04 21:02                                 ` Alireza Haghdoost
2016-03-04 21:52                                   ` Another Sillyname [this message]
2016-03-04 22:07                                     ` John Stoffel
2016-03-05 10:28                                       ` Another Sillyname
2016-03-05 10:47 ` Andreas Klauer
2016-03-09  0:23 ` NeilBrown
2016-03-12 11:38   ` Another Sillyname
2016-03-14  1:08     ` NeilBrown

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=CAOS+5GEr2p9nOcxWJxnX_u3_2PGyTfEPXnnzWYsMBWuXxSy-4Q@mail.gmail.com \
    --to=anothersname@googlemail.com \
    --cc=alireza@cs.umn.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).