Quoting Paul Flinders <P.Flinders@ftel.co.uk>:
> I have a failing disk which has a raid device consisting of
> two partitions in a linear array.
>
> I know that this is a odd and largely useless config - it resulted
> from my initial attempts to build raid configs on an otherwise
> spare disk which happened to have two partitions. The machine
> then got put into service with data on the raid device & it was only
> a week or so later that I remembered that I had intended to remove
> the RAID array and merge the two partitions into one large one. By
> then it was too late - /dev/md0 had data on it and I didn't have
> time to move it.
>
> As I said the drive is failing (it's read throughput has fallen to about
> 100K/sec!) and I'd like to get the data off before I send the drive
> for replacement. It's not critical (otherwise it would have been backed
> up) but it would be handy.
>
> I moved the disk to another machine, however the array won't start
> because it used to be /dev/hda{3,4} and is now /dev/hdd{3,4}. It
> was created with persistent superblocks.
>
> Is is possible to move the array to from /dev/hda to /dev/hdd?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
If you have an MD superblock edit utility to change the kdev_t fields on both
hda(3,4) to hdd(3,4), then you will be able to recover the data.
Alternatively, you can try EVMS MD support to recover your data. EVMS is an
open source project hosted on SourceForge. The url is:
http://www.sourceforge.net/projects/evms . The latest beta has support for MD
linear and Raid level 0, 1, 4 and 5. EVMS MD code does not depend on the kdev_t
fields. Therefore, you will be able to recover data.
FYI, EVMS (Enterprise Volume Management System) has been submitted for 2.5
kernel inclusion.
Regards,
Mike Tran
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
