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

Additional information for those interested.

During a PWRDWNSYS, even a *IMMED, the cache data is written to disk, **USUALLY**. This happens during the D9002740 that can sit on the panel/HMC for some time. The **USUALLY** is because there is a limited amount of time the system will allow for this to happen and if that time is exceeded the system shuts down and still could have some data in the cache. if your system was madly scrambling and updating lots of non-contiguous sectors when the power down began, it takes longer to clear the cache than if for example the last thing done was to copy a 100GB *FILE as that would generate lots of contiguous writes. THIS is why it's mandatory to 'FAIL' the cache batteries before replacing them and wait until the screen says it's 'Safe to Replace' the batteries. You might do a nice neat power down thinking cache is cleared but it's not and then you pull the battery.... cache is cleared now!

Now what if you get one of those honkin big 3GB Cache RAID cards and you have only 3 drives attached? That's some SERIOUS cache per drive and it would take a LONG time to write all that cache to those three drives wouldn't it? Well it turns out that IBM thought of that as well and they disable part of the write cache if too few disk units are attached specifically to avoid this situation.

Also consider if the power down began but did not complete before the UPS batteries checked out, dirty data in the cache once again.

As to how long the data hangs around the cache 'just because', that varies as well. Remember that on i at least these are true Caches, NOT just write buffers. This means that if an update to a sector occurs but before it gets written to disk it's updated again the first write will never happen to physical disk as it's replaced by the second write. Also reads that require data from that sector are satisfied (MUST be satisfied) from the write cache. There are three things that cause data to be written to disk:

Time. Too much time in the cache and out it goes. Many factors influence this including how busy the disks are.

Capacity. If the cache is too full, and data is incoming, the least recently used data is written out.

Proximity. If sectors in the cache are close to other sectors in the cache the card can use specific features including the i-specific 'skip-write' to write multiple sectors to a track in one pass. This means more data written with less physical disk activity and thus more write cache made available for other data.

Also note that just because data is flagged as written does not mean that reads requiring that data must come from disk, if the data is still in cache the read is satisfied from cache anyway.

- Larry "DrFranken" Bolhuis

On 3/30/2011 5:08 PM, Vern Hamberg wrote:

Paul

I think you're right, that the cache is a buffer. But the cache BATtery
is there in the event of a power loss - it has nothing to do with normal
write-cache behavior. If the system loses power, it can't empty the
cache back to disk - so something has to keep the cache activated until
power to the disks is restored.

Sound right?

Vern

On 3/30/2011 2:47 PM, Musselman, Paul wrote:

On a running system with nothing much happening, how long does data sit in the cache before it gets written to disk? I'm under the impression that the cache is there as a buffer between the electronic speed of the CPU and 'main memory' and the mechanical speed of a spinning disk. So, theoretically, at some point on a quiet system all data eventually gets written to disk, so (maybe) if all power dropped and the system didn't realize the cache batteries were actually dead you might just get lucky and find your data really was written to disk. So I theorize...

But I wouldn't want to bet my career on a flakey cache battery!

--Paul E Musselman

ps-- I really like our UPS and the diesel generator out back!