Different controllers and raid software store the configuration in
different places (not always on drives or recovered from the drives)
and use it differently for recovery purposes. I "hope" that "this"
mobo can reconstruct the controller config from the drives and there
is good flexibility for swap out with similar or identical HW. Yes
this all seems doable but it is not clear to me how much of a PITA the
whole thing is going to be (including locating the 'right' HW).
Again, an example of why you shouldn't be comparing or
contrasting, because you don't have the needed information
to do so.
It's not "reconstruct", nor a matter of flexibility. It's a
matter of using same controller and similar enough bios
version that there wasn't a sweeping change. In other
words, the chipset manufacturer does document if/when bios
changes are significant enough to cause loss of data. User
should not write to drive, merely hook it up and try it. If
the data is not readable then a look at the raid bios notes
is needed to determine where the version break-point was
that changed the parameters... and use the appropriate bios
version. This is usually not necessary, I only mentioned it
as a worst-case scenario.
Well of course, but how much can a novice really learn from manuals.
They learn what's important from doing (& from getting burnt).
Yes, this is why it's important to learn how BEFORE any
expectations of vital data storage... and at the very least,
have the restorable backup.
Not really making an ata raid comment per se. Only highlighting that
not all RAID HW & implemetations are equal (from a useability,
convenience, etc. standpoint) and sometime you can encounter a real
PITA for any number or reasons - including not being able to get an
identical board, compatibility with other readily available boards,
etc. Of course some product lines try harder to insulate you from
troubles - but that's not really the point I'm making.
I agree, but fortunately when one sticks to a very common
chipset with config-on-drives as these are, it's very easy
to recovery from a controller/board failure.
so all Promise cards & onboard chips are totally compatible? config,
CHS translation, LBA, driver always identical?
(really asking here)
I never suggested they were. All of the same chipsets are
compatible with same bios versions. Some of the chipsets
do support configs made by others, for example a Fasttrack66
can be read by a FastTrack100, IIRC, but only in bios prior
to introduction of 48bit LBA... or perhaps it was a
different version-break point, I'd have to look it up.
There are sufficient Promise chipset products that this
isn't necessary, and there may've only been one Promise
ATA133 chipset integrated on motherboards... I only recall
one.
Huh? you're going to flash some PCI card with what? for what
purpose?
Did you read what I wrote?
PCI controller card, flash different bios version, for
purpose of reading data IF the PCI card had a significantly
older or newer bios not compatible with the bios used on the
motherboard controller. You might have to do it before
you'd realize the simplicity in doing so.
How many variables are you going to change during the
recovery process?
This is really easy for someone accustomed to dealing with
Promise controllers:
- Same chipset
- If default/shipping bios doesn't work, flash different
bios per previous controller bios revision
What is hard about that? It takes about 1/10 the time it
took to write your post.
Normally all software levels have to match to work
properly (esp/incl driver). The more complicated you make this the
more likely you're going to muck things up - including messing up the
new raid card.
This is not complicated, you must have some preconceived
notion interfering with the simple two-step process... and
typically it's a one-step process, bios flashing isn't
usually needed, I only offered the info "just in case" it
was.
Maybe he should image the drives or backup certain sectors before
trying any suggestions esp w' experimenting w' different mobos or
cards?
It's real simple - Don't write to the drives, including NOT
making ANY changes in the RAID bios setup. The drives will
be read OK with zero config or you don't have the right
controller or bios version. Drivers are NOT needed for
RAID0. Well, if they were formatted as NTFS you do need a
driver for that, but it has nothing to do with the RAID or
controller... just windows NT/etc... hook it up in a working
system with the PCI card will be fine, and as with any other
hardware, you already had to know "somehow" what driver to
use, right? This is no different, all the needed info,
driver, is either included on the CDROM with product or
downloadable from manufacturer.
That would truly be magic as the mobo is toast & he can't locate
another. (This is where those multi-year warranties come in handy).
Nope, he'd either have to remember flashing the bios or
enquire about what bios version shipped on his revision of
the motherboard... or just download a bios from mobo
manufacturer... you don't need a board to determine info
about bios.
You mean from the image file DL'ed from the manufacturer? How does
that help if he doesn't know 'which' BIOS level he was using on the
original board?
You're making it seem hard, when it's usually not.
Why? What's the point of all this when it's relatively easy
to do it?
Just don't write to the drive. If you have one RAID bios
that doesn't work, try a different one. Whatever clues the
individual can gather to narrow down the bios version, might
help reduce the time it takes trying different bios, but
ultimately it's doable, repeatable, not luck or chance or
hope, etc, etc.
Those tools work with bios images, have no need for the
original board. As with anything else, I advise practicing
with them before doing something critical like flashing a
modded bios to a board... BUT, if user is capable of
flashing EEPROM another way too, it matters even less. I
suppose what it all boils down to is that the more skill
you have the more you can get away with doing... so long as
you already have a recovery plan rather than just a vague
concept that there might be some way to recover... which is
drifting off topic
That is a fair reason to be even more weary of motherboard
RAID controllers instead of separate PCI card, since the
odds of a motherboard failing are far higher than a RAID
card failing... especially in PC grade boards.
