[RndTbl] Big-endian RAID5 recovery problem

[Adam Thompson]

On 2017-05-02 03:59, Roman Mamedov wrote:
> On Mon, 01 May 2017 16:39:07 -0500
> Adam Thompson <athompso at athompso.net> 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