On 04/23/2017 12:23 PM, Patrik Dahlström wrote: > On 04/23/2017 12:16 PM, Andreas Klauer wrote: >> On Sun, Apr 23, 2017 at 11:47:34AM +0200, Patrik Dahlström wrote: >>> Is there any help you can offer? >> >> Is there any mdadm --examine output? > At this point, it is incorrect. I've lost the output from the working > raid too, unless it's located in any log in /var/log/. > I have /etc/mdadm/mdadm.conf, but don't know if it's updated. > >> >> What was on the array? Regular filesystem, unencrypted, or LVM, LUKS, ...? > Regular filesystem, unencrypted ext4. > >> >> If it's LUKS encrypted and you had RAID metadata at the end, yet >> mdadm --create'd new metadata at the start, that would likely have >> damaged your LUKS header beyond repair (and regular filesystems >> don't like it, either). > No file system encryption. > >> >> If it's unencrypted data, as a last resort you can always go and find >> the header of a large file of known type... for example if you find >> a megapixel JPEG image and the first 512K of it are part of that then >> your chunksize would be 512K and then you can go looking for the >> next chunk on the other disks... and that should give you some notion >> of the RAID layout and offset. > That's not a bad idea. Will hopefully narrow down my unknown variables. Okay, I extracted parts of an mkv file and this is what I found out: * playing 512 kb of data is OK * playing 1024 kb of data will give me the following error (from mpv): [mkv] Invalid EBML length at position 539473 [mkv] Corrupt file detected. Trying to resync starting from position 539473... "position 539473" is at ~527 kb, which leads me to suspect that the correct chunk size is 512 kb. Any thoughts? > >> >> Regards >> Andreas Klauer >> -- 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
