On 2017-05-02 03:59, Roman Mamedov wrote:
On Mon, 01 May 2017 16:39:07 -0500
Adam Thompson <athompso@xxxxxxxxxxxx> wrote:
I can't find any modern big-endian Linux systems... looks like all the
ARM distros run in little-endian mode.
Here are QEMU images for debian-mips (should be big-endian, as opposed
to
debian-mipsel): https://people.debian.org/~aurel32/qemu/mips/
Of course it will run purely in software, but most likely more than
fast enough
to copy away the data.
Not entirely sure that particular emulated MIPS system support more
than 4
drives), but it appears that a starting point could be (man
qemu-system):
Instead of -hda, -hdb, -hdc, -hdd, you can use:
qemu-system-i386 -drive file=file,index=0,media=disk
qemu-system-i386 -drive file=file,index=1,media=disk
qemu-system-i386 -drive file=file,index=2,media=disk
qemu-system-i386 -drive file=file,index=3,media=disk
with indexes 0..5, as you need the boot disk, all 4 drives, and one
more as
the backup destination.
May or may not be the best way, but IMO beats trying to hex-edit the
superblock right away.
So I now have:
4 x old IDE hard drives,
plugged into 4 x USB3-to-IDE adapters,
plugged into a 4x USB3 PCIe 1x adapter card,
plugged into an Ubuntu desktop i5 system @ 3.3GHz,
passed through into QEMU as virtual SCSI devices,
connected to a virtual AMD am53c974 SCSI adapter,
connected to a virtual Malta-series MIPS64 series,
emulated by QEMU.
Yikes!
The good news is that as soon as the Debian kernel booted, it
auto-detected the RAID arrays and started re-silvering them.
The bad news is: 1) that I thought I had attached the devices in
read-only mode (oops); and 2) it's re-syncing the MD array at
~5000Kb/sec.
I'll leave it to sync over the weekend (praying for no power outages),
but I sure hope I can upgrade the metadata block instead of doing this
all through a QEMU (non-accelerated) VM!
Thanks for the suggestions so far,
-Adam
--
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
