Hi,
I purchased a highpoint rocketraid 2310 controller and 4, Hitachi 1TB drives for a RAID 5 under windoz XP. The install was a nightmare, required multiple tech support calls and made Godzilla (xp host name) crash usually at least once per day. It would never come out of sleep mode correctly and many programs suddenly developed weirdness like locking up when writing files requiring a reboot to undo. Removing the controller fixed everything. It appears to not be compatible with XP on an an Asus A8N-SLI premium motherboard, fully patched.

I blamed uncle bill for xp weirdness and moved the entire array to Raptor, my Suse 10.3 workstation. I compiled their driver from source, nuked the sata_mv, ran modprobe, set acpi=off as a boot option, etc... I also had a Silicon Image 4 port PCI controller with 4, 250 drives in a RAID5.

Immediately, my machine refused to boot. It seemed to be caught in an infinite loop complaining about a corrupt superblock, --rebuild-sb, fsck.reiserfs /dev/md0 failed (status0x8). Run manually.

On my Western Digital Raptor boot drive, the internal tree check failed. I also got I/O errors on other drives. A total crash and burn.

I rebooted in rescue mode, edited out the "acpi=off" boot option and everything was back to normal except that my /dat drive, /dev/md0 would not mount.

I looked at with the Suse partition tool. The chunk size was changed from 128k to 4k and one of the 4 drives was no longer part of md0. I tried to force a mount in read-only mode, but it would not mount. I had hoped to run in degraded mode long enough to evacuate the data.

/proc/mdstat showed an apparently out of order drives sdd1, sdg1, sdf1 and sde1. They should have been d, e, f and g.

raptor:~ # fdisk -l
...
Disk /dev/md0 doesn't contain a valid partition table
raptor:~ # mdadm -E /dev/md0
mdadm: No md superblock detected on /dev/md0.

reiserfsck --check /dev/md0 showed:
journal parameters from the superblock does not match to the journal headers ones
The level of the node (65026) is not correct, (4) expected
Bad nodes were found, Semantic pass skipped
1 found corruptions can be fixed only when running with --rebuild-tree

Following Reiser's advise, I rebuilt the tree. It found hundreds of errors and took ~4 hours. Now, I have a mountain of short files in lost&found.

Is there any way to reassemble them? I had half of Star Trek and a ton of BBC videos there.

It appears that acpi=off may be implicated. What exactly did it do (or not do)? Has this controller destroyed many other arrays?

Thanks,
BrianP

I'm no expert at RAID or file recovery but your post shows the array contents have been subject to irreversible and destructive action (aka "repair") w/o any evidence of backups made prior to that. With the contents in lost+found as indication you could guess what any guarantee for recovery would be worth.