Un-raiding a two-disk fakeraid array

I have a system with two disks in a bios-configured RAID-1 array, currently dual-booting Win7 and Ubuntu 10.10. I opted for fakeraid, rather than softraid, so that the raided disk could be seen from both Win7 (gaming) and Ubuntu (everything else!). For various reasons, I've decided to back out from running this system with a raided disk, so I would like two separate disks: one for the two OS versions, and one for data.

I removed the RAID setting in BIOS, and rebooted. Both OSes boot OK, but I can't tell what's happening with the disk config. When I list the mount table, I still the /dev/mapper entries that were familiar from fakeRAID:

$ sudo mount | grep /dev
/dev/mapper/pdc_beidbcaig5 on / type ext4 (rw,errors=remount-ro,commit=0)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
/dev/dm-1 on /mnt/windows type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
/dev/mapper/pdc_beidbcaig9 on /home type ext4 (rw,user_xattr,commit=0)
/dev/mapper/pdc_beidbcaig6 on /var type ext4 (rw,commit=0)
/dev/mapper/pdc_beidbcaig7 on /boot type ext3 (rw,commit=0)

If I start gparted, I can see the partitions of the two mirrored disks, listed separately for /dev/sda and /dev/sdb. However, when I ask for information on any partition displayed in gparted, I get a warning:

Warning: no such file or directory while trying to open /dev/sda5
Couldn't find valid system superblock

dumpe2fs 1.41.12 (17-May-2010)
dumpe2fs: No such file or directory while trying to open /dev/sda5

Unable to read the contents of this file system!

Now clearly the file system can be read, because otherwise it wouldn't boot. But equally clearly something is awry in the disk configuration. Sadly, I don't really know where to start.

I did read the man page for dmraid, and I thought that the -x option was what I needed. However:

$ sudo dmraid -x
About to delete RAID set pdc_beidbcaig
WARNING: The metadata stored on the raidset(s) will not be 
  accessible after deletion
Do you want to continue ? [y/n] :y
ERROR: Raid set deletion is not supported in "pdc" format

In summary, what steps should I take to ensure that my two previously mirrored RAID-1 disks become two separate independent drives, one of which I can reformat to store more data on?

Thanks!

OK, I found some helpful information in this thread. In particular, doing

sudo dmraid -rE

was helpful, though I had to manually patch /etc/fstab after that, reasonably enough. Still not sure that I've covered everything though, and I'd be happy to have an explanation of what dmraid does. Magic incantations to "make it all better" are OK, but I'd rather understand what I'm doing, at least in broad terms!

Interesting, I think I learned something new about dmraid today. Software RAID in general is predicated on the concept of inserting metadata onto the disk somewhere and then taking over those disks with a special driver and presenting it as a new virtual disk with a superset of new features.

Usually, if you were to remove the meta data, the actual stored data becomes lost, or at least the roadmap to it does. Consider a RAID 5 where data is spread around several disks, traditionally you can only mount a single disk, which was the RAID5 you just destroyed, therefore, no mapping exists to access your data.

I think you hit the trivial case of dmraid de-provisioning, since RAID1 is really a pure mirror of the other drive, the positions of your data and partition tables make sense. Now that the metadata is gone thanks to dmraid -E, the dmraid driver no longer has a reason to claim the disks and assemble the RAID, so you should never see those /dev/mapper entries again.

Reconfiguring your fstab was a necessary part of the migration, also, had you used filesystem labels instead of mount points, no fstab changes would have been necessary.

I don't know that this is part of dmraid design or not, either way I know I would never count on that feature with my data. I wouldn't expect MD to operate this way. I think you got very lucky and that next time you should backup all your data before you reconfigure your drives in an invasive manner.