Thread (7 messages) 7 messages, 2 authors, 2020-05-18

Re: RAID wiped superblock recovery

From: Phil Turmel <hidden>
Date: 2020-05-17 21:56:04

Hi Sam,

On 5/17/20 9:55 AM, Sam Hurst wrote:
Hi Phil,
[trim /]
My complete mdadm -E output:

sosh@toothless:/$ sudo mdadm -E /dev/sda /dev/sdb /dev/sdc /dev/sdd 
/dev/sdf /dev/sdg /dev/sdh
/dev/sda:
           Magic : a92b4efc
         Version : 1.2
     Feature Map : 0x1
      Array UUID : f3667bf3:e2b718c2:22cbea68:428ea6ca
            Name : toothless:WDRAID
   Creation Time : Sat Oct 22 10:52:47 2016
      Raid Level : raid6
    Raid Devices : 7

  Avail Dev Size : 5860271024 (2794.39 GiB 3000.46 GB)
      Array Size : 14650675200 (13971.97 GiB 15002.29 GB)
   Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
     Data Offset : 262144 sectors
    Super Offset : 8 sectors
    Unused Space : before=262064 sectors, after=944 sectors
           State : clean
     Device UUID : 08c24be4:d352cbb0:edd50ba7:3a70e02e

Internal Bitmap : 8 sectors from superblock
     Update Time : Sat May  2 09:49:27 2020
   Bad Block Log : 512 entries available at offset 24 sectors
        Checksum : b1df527c - correct
          Events : 2687251

          Layout : left-symmetric
      Chunk Size : 512K

    Device Role : Active device 0
    Array State : AAAAAAA ('A' == active, '.' == missing, 'R' == replacing)
[trim /]
quoted
quoted
So I've tried all six permutations of the devices showing as "spare" 
at the end and I can never get a sensible filesystem out when I do a 
--create.

Does anyone have any other ideas, or can offer some wisdom into what 
to do next? Otherwise I'm writing a shell script to test all 5040 
permutations...
It isn't just order that matters.   You must get the right data offset 
and chunk size.  Defaults have changed over the years, and offsets 
typically change (+/- 1 chunk) during reshapes.

You'll probably have to manually specify this stuff.  Be sure to use 
the latest released version of mdadm, even if you have to compile it 
yourself.

If your data offsets are at least a couple megabytes, consider 
partitioning these disks at the same time as you reconstruct--simply 
adjust the data offset for the start sector of the partition.  This 
will avoid future issues with stupid mobos.  (You aren't the first to 
suffer from this.)
So I've now tried doing this and sadly haven't really gotten anywhere. 
Given the output of mdadm -E, I've specified the chunk size as 512K, and 
the data offset as 134MB (given the reported offset of 262144 sectors * 
sector size of 512 bytes on the devices).
Your math is wrong.  Or rather, you are using the bogus power-of-ten 
definition of "MB" that disk manufacturers use to deliver less space.

Use 128MB.  Or better, specify "262144s".

I generally recommend using fsck -n to verify a combination, not mount. 
But that's because I generally don't bother with overlays.  (And why I 
get away with it...)
Apologies that it's taken a while to respond to your mail, I just 
haven't had much time to look at this during the week.
No worries.

Phil
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help