public inbox for linux-raid@vger.kernel.org
 help / color / mirror / Atom feed
From: Leslie Rhorer <lesrhorer@att.net>
To: antlists <antlists@youngman.org.uk>,
	Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: My superblocks have gone missing, can't reassemble raid5
Date: Wed, 19 May 2021 18:45:47 -0500	[thread overview]
Message-ID: <60de3096-95e8-ca32-3c83-982bf8409167@att.net> (raw)
In-Reply-To: <d3a8bd2d-378e-fe84-ab81-4ac58f314b50@youngman.org.uk>

On 5/19/2021 3:01 PM, antlists wrote:
> On 19/05/2021 20:01, Leslie Rhorer wrote:
>>> The ONLY time you can be reasonably confident that running --create WILL
>>> recover a damaged array is if it is still in its original state - no
>>> drives swapped, no admin changes to the array, AND you're using the same
>>> version of mdadm.
>>
>>      That's a little bit of an overstatement, depending on what you 
>> mean by "reasonably confident".  Swapped drives should not ordinarily 
>> cause an issue, especially with RAID 4 or 5.  The parity is, after 
>> all, numerically unique.  Admin changes to the array should be 
>> similarly fully established provided the rebuild completed properly.  
>> I don't think the parity algorythms have changed over time in mdadm, 
>> either. Had they done so, mdadm would not be able to assemble arrays 
>> from previous versions regardless of whether the superblock was intact.
> 
> 
> You said there's only three possible combinations of three drives. Every 
> change I've mentioned adds another variable - more options ...

	I meant 6, not 3.

> The data offset is not fixed, for one.

	All of the data offsets were 262144 sectors in the listed Examine were 
262144 sectors.

> Swapping a drive could mean 
> drives have different offsets which means NO combination of drives

	I think not.  That is to say, it is certainly not impossible for it to 
change, but it is quite unlikely.  For one thing, if the offset is more, 
then all the data will no longer fit on the device, which would be a bit 
of a disaster.

	My main arrays consist of 8 drives each.  Every drive in both arrays 
has been replaced numerous times, starting with 1T drives more than 10 
years ago.  Now they are all 8T drives.  All 16 have data offsets of 
262144 sectors, just like the report from his drives.  Note I have seen 
arrays with different offsets, and of course any array on a partition 
will have a different offset.

	So while it is possible the offsets on his drives have changed, it is 
not at all likely.  Again. likely or not, it will not hurt for him to try.

> Yes you can explicitly specify everything, and get mdadm to recover the 
> array if the superblocks have been lost, but it's nowhere as simple as 
> "there are only three possible combinations".

	The number of permutations of the order of three drives is precisely 
six.  The permutations are:

1, 2, 3

1, 3, 2

2, 1, 3

2, 3, 1

3, 1, 2

3, 2, 1

	The Examine stated it was 2, 3, 1, but the device order is not at all 
unlikely to have changed.  Once again, I was very explicit in saying the 
simple create may not work and if not he is facing some much more 
serious issues.  That was and is in no way incorrect.  The odds one of 
them will work are not terrible, and if so, he is in good shape.  Are 
you seriously implying there is no way any of them could possibly work? 
  Are you seriously suggesting he should not try the simple approach 
before digging deep into the data to try to figure out all the 
parameters when the system was shut down?

  reply	other threads:[~2021-05-19 23:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17  4:16 My superblocks have gone missing, can't reassemble raid5 Christopher Thomas
2021-05-17  4:23 ` Christopher Thomas
2021-05-17  6:28 ` Roman Mamedov
2021-05-17  9:30   ` Wols Lists
     [not found]   ` <CAAMCDec=H=6ceP9bKjSnsQyvmZ0LqTAYzJTDmDQoBOHSJV+hDw@mail.gmail.com>
2021-05-17 13:19     ` Roman Mamedov
2021-05-18 17:47       ` Phil Turmel
2021-05-18 18:31         ` Reindl Harald
2021-05-19 13:20           ` Leslie Rhorer
2021-05-19 13:41             ` Phil Turmel
2021-05-19 16:54               ` Leslie Rhorer
2021-05-20 19:37               ` Nix
2021-06-07  9:52                 ` Leslie Rhorer
2021-05-19 14:20             ` Andy Smith
2021-05-19 14:59               ` Leslie Rhorer
2021-05-19 14:48 ` Leslie Rhorer
2021-05-19 16:41   ` antlists
2021-05-19 17:03     ` Leslie Rhorer
2021-05-19 17:08     ` Leslie Rhorer
2021-05-19 18:00       ` Wols Lists
2021-05-19 19:01         ` Leslie Rhorer
2021-05-19 20:01           ` antlists
2021-05-19 23:45             ` Leslie Rhorer [this message]
2021-05-20 20:49               ` Nix
2021-05-21  4:07                 ` Leslie Rhorer
2021-06-07  9:55                   ` Leslie Rhorer
2021-05-20 20:48           ` Nix
2021-05-21  3:56             ` Leslie Rhorer

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=60de3096-95e8-ca32-3c83-982bf8409167@att.net \
    --to=lesrhorer@att.net \
    --cc=antlists@youngman.org.uk \
    --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