If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
On Tue, 30 Nov 2004 23:03:53 GMT, CJT
wrote: There's no need to hope, if the drives are physically and logically intact (that is - if the motherboard was the *only* failure point, no damage to drives) then same controller with same/similar bios will work. Are you sure no motherboard RAID stores configuration info on the motherboard? I don't need to be sure of it do I? I didn't set up the RAID. Yes, I am sure the OP's RAID config is stored entirely on the drives. |
#12
|
|||
|
|||
On Wed, 1 Dec 2004 09:51:57 +1100, "Kadaitcha Man"
wrote: kony wrote: "Hope"? This is an example of what I'd posted in a prior thread, that I advise one not to learn _while_ setting up a data storage subsystem but prior to doing so. That's where you made your mistake. Most normal people learn from experience. Not everyone has a pin-head that needs to be buried in a book for a long swot just in case they **** up. Maybe if your parents had molly-coddled you a little less. LOL. Yes they learn by doing, but the prudent choice for data storage would then be on devices and technology one has already learned, NOT just "hoping" later. "Most people" don't make regular backups either. "Most people" lose their data if/when something goes wrong. We could dwell on what not to do or what TO do. |
#13
|
|||
|
|||
On Tue, 30 Nov 2004 23:13:30 GMT, Curious George
wrote: I just hope that if he gets a 'new' motherboard (like from ebay or sometihing) the onboard controller can get the config off the drives.. "Hope"? 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. This is an example of what I'd posted in a prior thread, that I advise one not to learn _while_ setting up a data storage subsystem but prior to doing so. 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. I also suspect you've not spend enough time dealing with ATA RAID to be able to properly contrast it to any other... 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. There's no need to hope, if the drives are physically and logically intact (that is - if the motherboard was the *only* failure point, no damage to drives) then same controller with same/similar bios will work. Towards that end, if the motherboard RAID bios version is unknown it might be easier to use a PCI card to recover, 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. since flashing a different bios is likely far easier than determining the RAID bios version used on the old board 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. (if manufacturer didn't provide full documentation, though decompressing the motherboard bios version is an alternate method of determining this), 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. in the off chance that the default bios on such a PCI card wouldn't work... though it probably will. There are also bios tools like CBROM or awardmod http://awardmod.sourceforge.net/ that can even be used to extract the raid bios from the original motherboard's bios, and swap it into a new board's bios to ensure same raid bios version. but the mobo is toast... 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. |
#14
|
|||
|
|||
kony wrote:
We could dwell on what not to do or what TO do. No. Whatever I decide is it, is it. End of argument. |
#15
|
|||
|
|||
On Wed, 01 Dec 2004 01:45:59 GMT, kony wrote:
On Tue, 30 Nov 2004 23:13:30 GMT, Curious George wrote: I just hope that if he gets a 'new' motherboard (like from ebay or sometihing) the onboard controller can get the config off the drives.. "Hope"? 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. Uh huh. - so the logical drive configuration is simply read off the disks during post and need not be restored to the controller? That makes sense as NVRAM adds cost. Well that's certainly an argument for software or hardware assisted software raid. If the controller is the only problem than it's fast to be up and running again (even if you are out of warranty even drastic solutions are cheap & fast). It's also an argument against it - if the dying controller or other mishap also marked drives as offline you want to recover - or if you are performing tests and want to quickly switch between several configs. This is an example of what I'd posted in a prior thread, that I advise one not to learn _while_ setting up a data storage subsystem but prior to doing so. 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. I also suspect you've not spend enough time dealing with ATA RAID to be able to properly contrast it to any other... 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. There's no need to hope, if the drives are physically and logically intact (that is - if the motherboard was the *only* failure point, no damage to drives) then same controller with same/similar bios will work. Towards that end, if the motherboard RAID bios version is unknown it might be easier to use a PCI card to recover, 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. since flashing a different bios is likely far easier than determining the RAID bios version used on the old board 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. If drives get incorrectly marked offline it is not so simple. Things often misbehave when they are dying and sometimes users screw things up when they notice problems surfacing. But IF the drives are perfect & IF the user does his homework, it should be as painless as you say. 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. (if manufacturer didn't provide full documentation, though decompressing the motherboard bios version is an alternate method of determining this), 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. in the off chance that the default bios on such a PCI card wouldn't work... though it probably will. There are also bios tools like CBROM or awardmod http://awardmod.sourceforge.net/ that can even be used to extract the raid bios from the original motherboard's bios, and swap it into a new board's bios to ensure same raid bios version. but the mobo is toast... 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. |
#16
|
|||
|
|||
Curious George wrote:
(snip) Ever consider trimming the parts of the post that you're not responding to? This would save a lot of scrolling-down looking for something else to read. |
#17
|
|||
|
|||
On Wed, 01 Dec 2004 13:20:28 -0600, chrisv
wrote: Curious George wrote: (snip) Ever consider trimming the parts of the post that you're not responding to? This would save a lot of scrolling-down looking for something else to read. Sorry. I could've done that better. |
#18
|
|||
|
|||
"chrisv" wrote in message
Curious George wrote: (snip) Ever consider trimming the parts of the post that you're not responding to? This would save a lot of scrolling-down looking for something else to read. What 'else to read'? All I only see is lots of posturing. |
#19
|
|||
|
|||
Posturing?
What nerve! That's supposed to be your job Folkert! |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
How to setup (copy) the Data to Raid 1 Harddisk | hon123456 | General | 1 | October 29th 04 09:41 AM |
disabling RAID 0 without losing data - is it possible? | Austin Newton Rice | General | 15 | September 13th 04 04:48 AM |
What are the advantages of RAID setup? | Rich | General | 5 | February 23rd 04 08:34 PM |
to read data from RAID disk from another computer. | Zhang Weiwu | General | 3 | February 19th 04 12:24 PM |
help. ga-7vrxp raid trouble, compatability and warning | todd elliott | General | 0 | July 17th 03 06:50 PM |