Link to home
Start Free TrialLog in
Avatar of Admin_Chevron
Admin_Chevron

asked on

Error on Array Configuration Utility - #1063

Does anyone know what this error message mean:

"Logical drive 1 ( RAID 5 , in array A) has been configured with a stripe size unrecognized by ACU.

Use ACU to delete this logical drive and reconfigure it. If the deletion operation is not successful, delete and recreate array A. "

It is showing up on the Array Configuration Utility status message for the Array.
ASKER CERTIFIED SOLUTION
Avatar of David
David
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Member_2_231077
Member_2_231077

What version of the ACU are you using? is the array working currently? you have "Failed SCSI Drive" in the tags, do you have a failed drive or array?

Corrupt metadata gives "RIS copies do not match" or something very similar so that's extremely unlikely.
Well, you could have a version of ACU that isn't compatible with the RAID firmware.   Check both by reading release notes.   A failed drive will have nothing to do with the stripe size.   The message is explicit in that the area of metadata that reports stripe size X reports something that the ACU can't understand.   Corrupted metadata CAN explain this, but more likely problem is incompatibility between RAID firmware and mgmt software.
It's most likely the ACU version which is why I posted that first. I presume it's working since people normally say the post message and never get to the ACU.
Avatar of Admin_Chevron

ASKER

Hi,

Thanx for the information. Answers to the questions and also some background:

1. ACU Version: 6.40.11.0
2. Yes, the array is currently working. We did have a battery failure, which has been replaced and is working fine.
3. No, don't have a failed SCSI Drive. We did have one about 3-4 weeks back. The reason it's a tag is I didn't know what the error message meant and since it's deals with disks...
4. I doubt it is incompatibility with RAID Fireware and ACU version - We've had this server running as is for the last 2 years. The only thing that gets updated is OS Patching.

This is a very tricky server due to its use and the application loaded on it. As such, the server setup stays constant and so did the OS. We did a patch run for OS last year Sept. and then again this year Sept. Other than that, nothing else changes - ever!

Ok, I think we're just going to swap out the server - sounds like a safer alternative than deleting and re-building the array and drives.

Thanx a lot guys for the help and info.
I don't think there's anything wrong with it, I suspect someone has installed an old version of the ACU on top of the proper one. If you look at the revision history you can see that Version: 7.0.1.0  (17 Dec 2003) added support for larger stripe sizes. If the array was created with a 256KB stripe size for example and you look it with your version of ACU you will get exactly the error you are reporting.

 http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=uk&prodTypeId=15351&prodSeriesId=3884082&swItem=MTX-be350342eaa14dd5b864790135&prodNameId=3884083&swEnvOID=1005&swLang=13&taskId=135&mode=5
Send it to me dude, and I'll sell it as a working server. I'm convinced that the metadata is not screwed up and doing exactly what it tells you to do would not be the correct way to proceed. You have fallen foul of a master of hubris.

At the very least boot it from a current ACU boot CD when you take it out of production instead of looking at it with the installed version of the ACU that was written in 2003 that doesn't understand larger stripe sizes.

As far as I see it you've accepted a bum steer.
However ... since the firmware & ACU software are too stupid to bother checking for portability issues, and they each require different metadata layouts (no way of knowing if the 256K stripe turns on a bit, or is in a different byte offset) .. then you can not make the assumption that by even running ACU you haven't damaged the metadata.  

The big clue is that the combination results in telling you to blow everything away and start over.  Had I written the code I would have added logic to assign a record layout ID, and checked for a valid high/low range for compatibility of the ACU software.   My guess is that this draconian requirement to rebuild from scratch is a CYA that the developers wrote because they never added revision level detection, so they tell you to backup and start over rather than let you risk data destruction down the line.

Even if you get the compatibility back again, unless it is explicitly documented, you just can't assume that everything is in order.  If the developers want you to rebuild, take their advice. They wrote the firmware.    For all you know some obscure data structure is now corrupted that might only come back to bite you when you have a drive failure.



Utter twaddle. They wrote the version he is running in 2003, you've persuaded him it's faulty without even getting him to run the ADU or to run a later version of ACU.
You dont *think* there is anything wrong per your previous post?  If you are wrong, perhaps 100% data loss.  No problem, it isn't as if it is YOUR data.  How do you know for a fact that metadata hasn't been changed?  The OP never posted specifics on revision levels.  The manufacturer's message says the array can't be trusted.  

I've been writing RAID & storage configurators, firmware, diagnostics, test suites, and utilities since the late 90's, and have NDAs with HP, LSI, AMCC, and a dozen more manufacturers and am intimately familiar with the internals. I say be conservative, plan for the worst, hope for the best.   Unless you have specifics of the record layouts, details on the variations that both the firmware and the ACU software and know the rules by which fields can be modified, then you do not have the facts you need to tell the OP that his data is safe and that updating the ACU will fix it.  

If you can reference a document from the manufacturer's release notes or manual that specifically addresses this problem, then it is irresponsible to just try upgrading software and hope for the best. Even if there was such a document .. how do you know that this specific scenario has been tested by the manufacturer?

Plan for the worst, hope for the best.  

>You dont *think* there is anything wrong per your previous post?

Not until they run a more up to date version of the ACU (or post an ADU report) can one be certain. When they do post an ADU report or look at it with a more modern version of the ACU I will be able to tell.

The ACU doesn't write anything until you press "save changes" so it won't have updated the RIS.