Configuration:
2 WD 250 GB SATA drives in Raid-1 array is Drive C:
2 Maxtor 320 GB drives in Raid-1 array as Drive D:
1 WD Raptor 85 Gb drive standalone as E:.
WHen I booted up, I got the C drive OK and what appeared to be the D
drive, and the E drive, but a new Drive G: popped up I had never seen
before. Inspection of G: showed it to have the SAME files as on D:.
I then re-booted, pressed F10 and the Raid utility popped up as
expected.
Instead of 2 arrays, it showed C: as OK, D: and G: as degraded.(the
display did not have C:, D: or G: - it showed the appropriate volumes
- I used the singlew letters for brevity).
At this point, I highlightes the first degraded array (D:) and looked
ata the details. Ignorant of what to look for, I didn't know what to
look for, but at the bottom, I could choose to R- Rebuild the array.
I did so, but nothing. I then looked at the details of the other
degraded array (G:) - same thing- tried R - rebuild, but nothing.
Since I had booted sussceesfully before, decided to check the
differences between the two drives. D: had 5 more files than G: -
both at 147 mb. At this point I got a portable USB drive, n mounted
it and proceeded to backup the D; drive, since it presumablu had more
data than G:.
I now have a backup of the drive, but have done nothing since If you
don't know anything about it, leave it alone until you do. I have
refrained from writing on either drive to try to maintain status quo
until I know how to proceed.
I would like to know of anyone who experienced this and what you did
about it, or can someone direct me to a place where I can find a
solution.
Thanks for any and all replies.
John Carter
Now that you have a backup of the files in question, you can delete D and G
array entries (or whatever the two orphans are), and then create a new
array D:G. Then copy the 147GB of files back from the USB disk, to the
new RAID1 mirror D:G.
Somehow, the metadata on your RAID pair got corrupted. The metadata is how
the RAID driver you installed in the OS, figures out they're a RAID pair.
The metadata is specific. For example, if you're running RAID0 stripe, one
drive will be marked "odd" and the other drive "even", since the striped
data only makes sense, if the drives are read in a particular order.
The presence of the metadata, even means the drives can be moved from
one SATA cable to another, and their order and array association is
preserved. The metadata probably contains the serial numbers of all
the drives in the array, whatever type it might be.
I did an experiment on a pair of drives here. I used a Promise RAID
chip, zeroed two drives with dd (so every sector was zeros), then
created an array. Again, using dd, I visited the end of the disk, and
I could find a small area near the end, where 16 data structures were
located. I presume the format of that metadata, could hold up to
16 array descriptions. I didn't go any further than that (didn't go
looking for drive serial numbers).
If a person were to record the metadata, and save it away, along
with notes on the starting sector address, in theory they could do
"metadata surgery". But deleting an array, and creating an array
again, can do much the same thing.
The troubling question is why it broke in the first place.
Bad driver ? Power interruption ? Cache flush not happening
properly at shutdown ? How much trust can you have in a
mechanism, that displays how fragile it is ? It is one thing
to see a single array entry with a degraded status, that you
fix by doing a rebuild, and quite another to have orphans.
If you're running RAID, I recommend the computer be on a UPS,
to encourage better consistency between the mirrored volumes.
You would use a UPS with a data cable that connects to the
computer, and the UPS can signal the computer when it should
start its shutdown sequence. You lose any open files that way,
but the orderly shutdown while on UPS batteries, means your
array is preserved. If the power goes off suddenly, the design
of the typical desktop RAID, doesn't offer any guarantees.
I'd actually be happier, if you reported this happened after
a power failure, as at least that gives an excuse for a corruption.
There have been other weird cases. Someone had a SIL3112 once,
with two drives on it, set up as a RAID1 mirror. One day, they
got an error message. One disk was gone. But the funny
thing was, the other disk (which should have been a perfect
mirror), had file content consistent with three months previous.
In other words, the "mirroring" of files had stopped three
months previous. And the user had effectively lost three months
worth of files. Now, maybe that system had a broken mirror
for three months, but the person making the report claims
there were no warning messages previous to the discovery.
So the disk that broke, might have had current files, while
the supposed mirror disk, was three months behind.
That's the kind of stuff that scares people. And is a good
incentive to be backing up the mirror anyway.
Paul