Re: MD RAID6 corrupted by Avago 9260-4i controller [SOLVED]

Wolfgang Denk
2016-05-15T23:10:46Z

Dear Andreas,

In message <20160515203446.GA13218@EIS.leimen.priv> you wrote:
>
> That's strange, if it worked once, it should work twice (if no changes
> were made outside of the overlays). If you have created the udev rules
> file, just in case there is a side effect, remove it again ...

NO, I think it's me to blame. If I read the bash history correctly,
I made a mistake (confusing $DEVICES and $devices and $overlays)
and ran the --zero-superblock on the real disk devices, not the overlays.

On the other hand, that should not make a real difference if it worked
for the overlays. Well, it does...

> What does mdadm --examine /dev/mapper/sda say before and after
> you --zero-superblock? (is it the same for the other disks?)

--zero-superblock now porperly reports that it cannot find a
superblock...

> If it's LVM, you could search the first few hundred megs of your devices for
> the LVM header, that should be the data offset you're looking for.

Ok, but...

> That's LABELONE at offset 0x200 and you have to substract 512 bytes from it,
> so this is actually what it would look like for offset 0.

That would be the --data-offset= parameter?

> Alternatively this can also be done using
>
> dd bs=1M count=1024 if=... | strings -t d -n 8 | grep LABELONE
> 512 LABELONE
>
> if your version of strings supports this option.

It does - but I'm confused as I get a number of different values from
the devices:

# for i in /dev/mapper/sd? ; do
> echo $i
> dd bs=1M count=1024 if=$i | strings -t d -n 8 | grep LABELONE
> done
/dev/mapper/sda
139776 LABELONE
...
/dev/mapper/sdb
...
/dev/mapper/sdc
396826104 LABELONE
...
/dev/mapper/sdd
...
/dev/mapper/sde
387503608 LABELONE
389663524 LABELONE
...
/dev/mapper/sdf
398969636 LABELONE
...

So I have 5 numbers; minus 512 and converted to kB gives:

139776 -> 139264 -> 136
396826104 -> 396825592 -> 887524.99
387503608 -> 387503096 -> 878410.99
389663524 -> 389663012 -> 380530.28
398969636 -> 398969124 -> 889618.28

Of these, only 136 appears to make sense. But running

# mdadm --create --verbose /dev/md2 --metadata=1.2 --level=6 --raid-devices=6 --chunk=16 --assume-clean --data-offset=136 /dev/mapper/sd?
mdadm: layout defaults to left-symmetric
mdadm: size set to 976762448K
mdadm: automatically enabling write-intent bitmap on large array
mdadm: array /dev/md2 started.

...creates an array, but LVM does not recognise it.

Searching the resulting /dev/md2 for the LABELONE does not find any.

Am I misinterpreting your information?

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The sixth sick sheik’s sixth sheep’s sick.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html