2017-04-25 12:40 GMT+02:00, Patrik Dahlström [off-list ref]:

2017-04-25 11:01 GMT+02:00, Andreas Klauer [off-list ref]:

quoted

On Tue, Apr 25, 2017 at 10:44:15AM +0200, Patrik Dahlström wrote:
You found multiple filesystem headers, do you know the UUID it should
have so you're not working with some old remnant?

The file systems looks correct:
$ grep storage /etc/fstab
# commented out during recovery
#UUID=345ec7b8-b523-45d3-8c2e-35cda1ab62c1 /storage        ext4
errors=remount-ro 0       1
$ file -s /dev/md0
/dev/md0: Linux rev 1.0 ext4 filesystem data,
UUID=345ec7b8-b523-45d3-8c2e-35cda1ab62c1 (extents) (64bit) (large
files) (huge files)
$ file -s /dev/md1
/dev/md1: Linux rev 1.0 ext4 filesystem data,
UUID=345ec7b8-b523-45d3-8c2e-35cda1ab62c1 (extents) (64bit) (large
files) (huge files)

This actually got me thinking. During my destructive recovery
attempts, I would either don't specify a --data-offset or use
--data-offset=128M. Since the correct offsets are less than 128M
(123,5 MB actually), that data would be untouched in case a
reshape/rebuild was triggered by my attempts. That must explain why
the first 4 chunks of /dev/md{0,1} were identical when using correct
offset, right?