Thanks for these insights. When I said I'm not a super user, I meant I'm not elite, not that I didn't have super user permissions.
[which just reinforces that I'm not a l33t user]
Thanks also for pointing out that the disk order is printed on the motherboard.... I hadn't even thought to look there, but you're right the "top" disk is SATA 1 and the bottom disk is SATA 2.
I don't have the drives connected directly to the PC's motherboard. I'm using USB to connect them.
What I've tried so far, which doesn't work (just for others that may view this thread later):
1. After connecting the 2 drives via USB to my PC, R-studio and the Runtime.com programs could see the disks mounted via USB but neither could correctly rebuild the RAID 0. They wanted the block size and start sector to reconstruct the RAID. Since I don't have that, I abandoned those programs. [Also, I did try to scan the RAID with the default settings in the runtime program, and it recovered some files, but only the small ones and not the file structure. Larger image files or .pdfs were 'recovered' but not openable.]
I downloaded UFS Explorer Raid Recovery and made images of both disks on another drive (mainly so I wouldn't keep re-scanning the original disks), and it seemed to do a bit better (and with your help, I was more certain about the drive order and the default stripe size 64K).
According to UFS, drive 1 has 4 partitions: EXT2/3/4 (sector 63, ~1 gb), SGI XFS (sector 2008125, ~4.77 GB), unknown partition (sector 12016683, ~1 GB), and SGI XFS (14024808, 458 GB---the one Windows disk manager sees as health with files)
According to UFS, drive 2 has 4 partitions: EXT2/3/4 (sector 63, ~1 gb), SGI XFS (sector 2008125, ~4.77 GB), unknown partition (~1 GB), and *unknown* partition (458 GB---the one Windows disk manager sees as health with files)
When I use UFS to rebuild the RAID0 (using the images), the virtual RAID has 3 partitions listed: EXT2/3/4 (sector 63, ~1 gb), unknown partition (sector 2008125, ~4.77 GB), unknown partition (12016620, ~460 GB). This doesn't look right, though I'm not certain what it should look like, other than I should have closer to 800 GB of data, not 500GB. So now, I'm running "find lost partition" on the Virtual Raid0, and it's only 1/2 way done but has found 2 XFS partitions that are large.... one that's 896GB and one that's 916GB, and I'm wondering if one of these is my pre-format mishap data partition and the other is the 'new' post-mishap partition. UFS is also finding lots of FAT file systems, too. When it finishes, I'm going to see if I can "recover" the files.
2. In the meantime, I also took the 2 original physical drives and reassembled the LS Mini. I reconnected it to my network and turned it on. Lots of blue lights flashing and the navigator couldn't see it. So, I turned it off. Held down the function button, and turned it back on, pushed the function button once, and now it's back on the network: NAS Navigator can see it, and I can browse to 192.168.1.6 and log in. I can also FTP to the drive, too. However, all my shares are still missing (so it's back to the state is was right after the firmware update/format and before I took it apart). [BTW, recreating the root shares does not work for me, though it worked for some others....] I'm ready to try 'telnet'ing or SSHing into the drive as recommended here, but am not sure what to do once I get there. Will that work even though the file system is missing/broken?
3. The thing I haven't tried yet is to use Linux to assemble the RAID (and thanks for the tip about mdadm.... the other instructions say create). I worry that it won't work partly b/c it already has a RAID0, the one the firmware update created. I need it to go back to the earlier one. Or to let me access the old one before the firmware update. I'm starting to suspect that this won't let me do that. How will it assemble the RAID from before and not the broken one it has now?
Thanks again. Most of the detail above is just to document what I have/have not done in case it's of use to others.