On 2017-05-01 Adam Thompson wrote: > The problem is that the disks use the v0.90 metadata format, and they > came from a big-endian system, not a little-endian system. MD > superblocks *since* v0.90 are endian-agnostic, but back in v0.90, the > superblock was byte-order specific. This may sound crazy, but conceivably you could (using the md source code) find where the superblock lives (just the first copy should be enough), hex edit the superblock and (again using the source) swap bytes around to change the endian-ness. Then make sure any future mdadm commands are just using the first superblock (which I think is the default). If there's some kind of checksum involved, then the endian-ness may affect it (??), and fudging that may be quite difficult (compared to finding a big-endian box out there to borrow instead!). No matter what you do, I would instantly dd each real disk into files in your own big fs and work on the copies. No reason to ever write to the originals, keep them as backups. I *think* you can use mdadm on plain files(??) otherwise I guess you could subpartition a big disk. Ya, it will be cheesy to run RAID5 all off of 1 disk, but in this case performance won't be critical. Lastly, I would make sure to start the array in such a way that for sure it won't resync, so either get all 3 preset perfectly, or leave 1 as missing, or I think there's a command to not start if it would result in a dirty array. -- 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
