Chris Eddington wrote:

Hi,

Thanks for the pointer on xfs_repair -n , it actually tells me something
(some listed below) but I'm not sure what it means but there seems to be
a lot of data loss.  One complication is I see an error message in ata6,
so I moved the disks around thinking it was a flaky sata port, but I see
the error again on ata4 so it seems to follow the disk.  But it happens
exactly at the same time during xfs_repair sequence, so I don't think it
is a flaky disk.

Does dmesg have any info/sata errors?

xfs_repair will have problems if the disk is bad. You may want to image the disk
(possibly onto the 'spare'?) if it is bad.

 I'll go to the xfs mailing list on this.

Very good idea :)

Is there a way to be sure the disk order is right? 

The order looks right to me.
xfs_repair wouldn't recognise it as well as it does if the order was wrong.

not way out of wack since I'm seeing so much from xfs_repair.  Also
since I've been moving the disks around, I want to be sure I have the
right order.

Bear in mind that -n stops the repair fixing a problem. Then as the 'repair'
proceeds it becomes very confused by problems that should have been fixed.

This is evident in the superblock issue (which also probably explains the failed
mount).

Is there a way to try restoring using the other disk?

No the event count was very out of date.