|
Yeah, I wouldn't advocate it, but at least you know its there if theyou
system decides to end caching in the middle of the day when the system is
needed the most. What a great day of learning for me. haha.
Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777
Vern Hamberg<vhamberg@xxxxxxxxxxx>
Sent by:midrange-l-bounces@xxxxxxxxxxxx
03/30/2011 09:45 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
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:
unreliableWhat 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
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
thencould get your performance back while waiting on a replacement, but
Ithink
remembered hearing that you can reset the clock to make the system
Questionit 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. :
-of a Newbie to POWER Systems
Bryce
Interesting question - seems to me that the cache battery is a backup
Theit preserves anything in the cache in the event of a power outage.
outsystem 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
have- 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
isto be done synchronously, not through the cache, because the backup
writenot 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
raidcache the better. Ask anyone who has lost the batteries on the
poorsource?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
If the cache batter goes shouldn't the controller still have enough
electrical input to keep its cache alive? This just seems like
purpose isdesigndesign, and a major oversight. Maybe I don't understand hardware
(that is probably the case), but I'm failing to see what the
--thinkof
the battery vs straight electrical input from the system? I would
don'tyou'd want a cache battery in the case of a hardware failure so you
lose data, but I would think that it should be a backup source....
Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.