How can a RAID5 ICH10R array be repaired when IRST ignores requests to rebuild?

[silekonn]

The board is an EX58-EXTREME with F13u modded (here). The ICH10R four-disk RAID5 shows one disk is missing, on an unknown port and unknown port location. Multiple RST versions have been attempted and RAID BIOS 13.2.0.2134 was installed (from 12.6.0.1867). 'Rebuild to another disk' sets the missing drive as 'spare' and does nothing. The drive is functional and does not have evidence of failure (SMART is OK), the problem is due to damaged metadata. Please view the screenshots for detail: Intel_RAID5_Problem - Imgur. If the option to backup/rebuild this 6TB array elsewhere was available it would have occurred . Your assistance is appreciated.



Thank you,

R Lewis

[parsec]

Re: How can a RAID5 ICH10R array be repaired when IRST ignores requests to rebuild?

Ah, the venerable ICH10R, I used it on my X58 board, and they were used on some Intel 4 series chipset boards I owned.

By "RAID BIOS", I assume you mean the RAID Option ROM, that is part of a BIOS/UEFI file?

Starting with IRST version 12, the ICH10R is no longer on the list of supported chipsets, sorry to say. That of course includes the RAID Option ROMs.

For example, from the IRST 12.0.0.1083 Readme:



Check the IRST Readme files from the links on this page, version 11.7.0.1013 (of those that are available from Intel) is the last to support the ICH10R:

https://downloadcenter.intel.com/Sea...ng&ProdId=2101

My point is any non-standard behavior in rebuilding this RAID 5 array can be caused by the mismatched IRST Option ROM, and I assume full IRST package installed on that PC.

Since you are only in the Degraded state, and you claim the disk is fine (your screenshots of HWiNFO only show three drive's information) you should be able to rebuild the array, after you mark the problem disk as Normal. This assumes the disk is truly working correctly.

In the Status or Manage disk section, you should be able to set the failed disk's status to Normal. I assume you don't have that option? Once set to Normal, the array would start to rebuild automatically.

Setting the disk to Normal deletes the metadata, and all data on the disk. Deleting RAID metadata is not easy, a standard Windows format will not do it.

Your other option is to replace the drive, as you know.

[silekonn]

Re: How can a RAID5 ICH10R array be repaired when IRST ignores requests to rebuild?

The drive is already normal. Later last night I realized the problem. The drive in question was the first in the array and was affected by some software or otherwise. The HWiNFO screens demonstrate the drive has identical geometry to the three functional drives, aside the 48-bit LBA. Something has altered it and the drive is 4MB smaller (also in the pics). Will a zero-write correct the size? My concern was the answer to that is 'no' and some sort of hex or geometry edit is required. Please inform me.

Thank you,

Ryan

[parsec]

Re: How can a RAID5 ICH10R array be repaired when IRST ignores requests to rebuild?

Good call on the "missing" LBA's on that drive. Why it's like that, who knows. Perhaps the drive is bad but not caught by SMART.

So that drive has a status of Normal, and the RAID 5 array does not auto-rebuild? Not a good sign, that is what should happen. The auto rebuild on hot plug option should not need to be enabled in this case, but is that enabled anyway?

Try the zero fill, otherwise I have no idea why that drive is short 8,257 48 bit LBAs compared to the other drives.

You seem confident that IRST option ROMs and drivers not specified for the ICH10R are nothing to worry about. Intel just does that for no reason, right? The ICH10R originally used the Intel Matrix Storage Driver, before IRST existed.

New does not automatically mean better, the fastest version of IRST is known to be 11.2. Have you ever read the list of known bugs in every official version of IRST, in the Release Notes? Dozens of issues in every version. I know of at least two officially released versions of IRST that were later removed from Intel's downloads due to problems.

[silekonn]

Re: How can a RAID5 ICH10R array be repaired when IRST ignores requests to rebuild?

The drive is not faulty. This occurred as a result of flashing a separate host adapter. It is a Rocket 640L and after years of no updates they finally had some firmware on their site, two versions. A quick check on the internet noted it fixed a 'resume from sleep' issue.

It was flashed. It may be designed only for MacBook Pros, they failed to name the file or notate it in the changelog/readme. The card freezes the system when the BIOS should initialize.

The drive geometry of the first drive in a four-disk array was altered during this process. A suspicion is that firmware affected it. Windows may have somehow written and the lockups caused a CMOS reset. The system wouldn't progress to loading Windows while the card was installed.

I am aware of the removed IRST versions, the system has employed RAID5 back as far as the MSM days. Version 11.2 being the highest performance is true and it is the first version to support TRIM. I do browse the known problems and changelogs. I didn't notice anything, it may be worth another look.

Intel phases out support for products as any company. What is different is that they often don't remove support. Have you ever tried the 10-version chipset support on nine or 800-series systems? It will work because the last versions for those systems are included. The 13-series drives don't improve upon X58. They don't 'break' it because the support exists. The benefits, minor and to me worth a risk, are U. I. improvements. An example is this scenario, 12-series drives didn't even offer the 'rebuild to another disk' option. They should have as it is listed in the documentation back as far as Matrix Storage Manager (version eights).

Auto hot-plug rebuild is an option in 13 and it is off by default. It was toggled and had no effect. A 1TB drive is offered as a rebuild to another disk option demonstrating how they programmed. The problem is likely rebuild cannot be completed without a disc of equal or greater size.

The only question is, "will a zero-write correct 48-bit geometry, and if not, how can that be accomplished." I intend the attempt in the near future. Someone knowledgeable on this subject would be appreciated. The finding alters the original question, this new problem may be posted in Storage Devices and Methods, pending the attempt.

Thank you.

Ryan

P. S. How do you like your 512-gig MX100? I was updating the firmware prior to installation of mine. I was previously always an Intel/Samsung guy.

[parsec]

Re: How can a RAID5 ICH10R array be repaired when IRST ignores requests to rebuild?

Any chance that one drive was formatted as GPT?

Speaking of firmware updates, any chance there is a firmware update for that drive? Even if you "updated" it to the same firmware version, performing the update might clear the LBA table, etc.

I assume SMART is not saying there are any bad sectors/blocks on the drive, but if there were and they were excluded from the accessible LBAs, would you not see what you do now?

Doing a zero fill/secure erase of that drive will not make any difference in the recovery of your RAID 5 array. Meaning that drive will be rebuilt with the parity data from the other drives whether you zero fill it or not. The question remains, why won't the array rebuild when that drive is in the Normal state?

Which is why I question the use of the unofficial (per Intel) versions of IRST, particularly the option ROM. Do I know with certainty that using the versions of IRST apparently not compatible with the ICH10R will be a problem? No, but IMO do we know that they won't? Again, no. I'm aware of the use of driver versions not released with a chipset, and do that myself. But through IRST 11, the ICH10R was included, and now it isn't. Is that simply for wont of "support", meaning testing/validation? It could be.

But things can change. The Intel 8 series chipset SATA controllers (and beyond) will not work with SSDs that use the SandForce 1200 series SSD controller. Those SSDs are not detected consistently by this hardware.

All I am saying is, IRST did not seem to be behaving as it should be given your situation. IMO one of the potential reasons could be the use of IRST software versions that are not specified for use with your hardware.

The Crucial MX100 SSD is great, nothing wrong with it at all. Some like to say it is "slower" than other SSDs, when looking at one simple benchmark. I've seen other tests where it is at the top or near the top. (Not aimed at you) Does this look like a slow SSD?



The MX100 is not meant to be high end SSD, not that most users ever put a load on their SSDs that will reveal a performance difference. Intel and Crucial collaborate making NAND in their Micron business, so I'm not worried about the NAND being poor. I have Crucial M4 SSDs that still work fine, IMO Crucial is among the best SSD manufactures. For those wanting cheaper, high capacity SSD storage, there it is.