2017-04-25 12:40 GMT+02:00, Patrik Dahlström <risca@xxxxxxxxxxxxxxx>:
> 2017-04-25 11:01 GMT+02:00, Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>:
>> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
