yes sorry i did read about udev rules, i just wasnt sure if i can edit existing raid arrays to use the udev rules without re-creating them.

I know there is no way to convert software raid to fake raid, but if i cant access my 1tb of stuff anyway theres no difference.


By rebuild min speed, i meant /proc/sys/dev/raid/speed_limit_min sorry.

And yeah the green drives dont have varible spindle speed. Some people say they do but im 99% sure they dont.

Sorry, i understand all your posts, they are helpful. I am just stuck on why changing a drive letter makes the array borked.
If raid 0 has the data split over the two drives (striped), why does chaning the drive letter make it not work? Yes i know it looks at the orignal drive letter and says "HOld on, this isnt that drive, array cannot start", but why cant i say to mdadm "Build the array from these two drives, they are the correct two drives"? mdadm should see that the data has not changed since a reboot, and even if it has, it should still be able to try and match the data and its headers to try its best to recover most of the data on the drive. I wouldnt mind if it took 60h or so to sift though the data, would save me 12months of downloading stuff i have lost as in Australia i only have 60gb of downloads per month.

The udev rules would specifiy which drive gets tagged as "sda", "sdb", etc, etc. You wouldn't have to rebuild or reinitialize anything.
As long as you setup the rules correctly, you'd be fine.

Wait, I thought you said the 2 x 500GB RAID-0 array was a temp drive you used to shuffle data around? I take it that's not the case...You should be able to change the speed_limit_min at any time. Not sure if it's going to notice the change while a rebuild is in progress, tho.I could have sworn I read a spec sheet for a WD Green drive that said "5900 to 7200 RPM", but I could be mistaken.Because you had the "DEVICES=/dev/sdX#" lines after your arrays, so when the assignments changed, the wrong drives were getting forced into the wrong arrays. That's why you should always set "DEVICES=partitons", so everything gets scanned.

Because a RAID-0 cannot run in "degraded" mode like the other levels of RAID. If one drive "fails" (either really fails, or 'fails to init' because the device name changed), then the array is borked. It's a stripe with no redundancy.


Nope, that's not what it says. It's more like "OMG! The Stripe has gone bad! DIE! DIE! DIE!"


You can, you have to reinit the stripe (recreate it, which will toss your data).

It *cant* confirm that the data hasn't changed. There's no parity information stored in a RAID-0 that it could use to do consistency-checking.

There is no data to "match", that would require either a 2nd copy of the data (like in RAID-1), or pairty information per-stripe (like RAID-5).

Again, nothing to recover, because RAID-0 does use parity.

All of the capabilities of RAID-0 are listed in your previous post. Namely, that it just takes N number of X sized drives and creates an array that is pretty much N*X big. RAID-5 sort of does N*X-1N, and RAID-10 does N*X/2.

It's a royal pain, and I've had it happen to me before. However, I did have backups. I would suggest getting 4 x USB sticks and play around with creating a set of udev rules for them, then "port" the rules to your hard drives.

Note: Don't reboot while playing with the USB sticks, you'll knock your lettering out again unless you have "DEVICES=partitions" set this time.

Lots of luck, mate!
And don't forget to rate the posts that helped you, just incase someone else winds up in your shoes!