Re: Cache battery and Raid Controller Design WAS: Re: Rép. : Question of a Newbie to POWER Systems

Bryce

I have sort of done what you speak of here, but for a new battery pack. It somehow didn't register - or I didn't do the procedure correctly. Anyhow, forcing the error condition, then doing the procedure again with the same battery, did reset things. This was when I felt that I knew it was a good battery pack. This was also a box that is not in constant use, and we are a software house, so our needs are different from regular customers.

The aging of the battery is based on time and on environment - specifically, temperature. If it is warmer, IBM thinks the life will be shorter. Some of the packs actually have a connection for a temp sensor, as I recall. You can get a pack through non-IBM sources, but they will not have the temperature bit.

But if the pack has been there a while, I do not recommend faking out the system. I did it when I put in a spanking brand-new one. I got lucky - it's still working fine, no slowdown, etc.

Vern

On 3/30/2011 8:00 AM, Bryce Martin wrote:

What you and Jim say makes sense. Its more of IBM making you go from
cache to synchronous when they feel the cache battery might be unreliable
instead of waiting for it to fail and you possibly losing data.

I was going to suggest a way to somehow override the system so that you
could get your performance back while waiting on a replacement, but then I
remembered hearing that you can reset the clock to make the system think
it was replace correct? Because doesn't it just work on some sort of
clock hours??


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



Vern Hamberg<vhamberg@xxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
03/30/2011 08:49 AM
Please respond to
Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Cache battery and Raid Controller Design WAS: Re: Rép. : Question
of a Newbie to POWER Systems






Bryce

Interesting question - seems to me that the cache battery is a backup -
it preserves anything in the cache in the event of a power outage. The
system could and probably does use the regular power of the system
during normal operations.

The matter of slowing down when the cache battery's life is running out
- I think this happens for a different reason - if the battery can't
keep data in the cache, then you can't rely on the cache. So writes have
to be done synchronously, not through the cache, because the backup is
not trustworthy. This slows it down.

I've not thought of this at all, so my ideas can be far off base!

Vern

On 3/30/2011 7:32 AM, Bryce Martin wrote:

Jim Said....
"Write cache has a massive impact on I/O performance. The more write
cache the better. Ask anyone who has lost the batteries on the raid
card what happens when write cache goes away. Ugly things happen."

This got me thinking about RAID Card design....

Why the heck isn't the cache batter a backup, not a primary power

source?

If the cache batter goes shouldn't the controller still have enough
electrical input to keep its cache alive? This just seems like poor
design, and a major oversight. Maybe I don't understand hardware design
(that is probably the case), but I'm failing to see what the purpose is

of

the battery vs straight electrical input from the system? I would think
you'd want a cache battery in the case of a hardware failure so you

don't

lose data, but I would think that it should be a backup source....

Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777
--- This message (including any attachments) is intended only for the

use of the individual or entity to which it is addressed and may contain
information that is non-public, proprietary, privileged, confidential, and
exempt from disclosure under applicable law. If you are not the intended
recipient, you are hereby notified that any use, dissemination,
distribution, or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify us and
destroy this message immediately. ---