× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



See in line answers

On 2/16/2021 9:09 AM, Patrik Schindler wrote:
Hello Larry,

Am 16.02.2021 um 14:04 schrieb Larry DrFranken Bolhuis <midrange@xxxxxxxxxxxx>:


To force that to YES you work with resources containing cache batteries and forces the card to flush the cache.

Some curiosity-thoughts:

How comes that a disabled cache needs flushing anyway?

In theory it does not. But a forced flush assures that it IS flushed. If you've been running degraded for more than a few minutes the cache likely is already flushed as you surmise. But it's like yanking the door handle after locking the door. SOMETIMES it pops loose so locked or not it wasn't secure!


How comes that a hosed ASP can be "lost" (whatever that means)? Pulling the mains plug in the middle of heavy writes to an ASP on a "normal", non RAID machine triggers yields an extended IPL time and probably access path recovery. Of course, data can be lost, but the whole ASP?


Well that's the thing about the batteries. When you pull the plugs (bad) the data in cache is held by the batteries. When the power comes back on that data is written to disk with the quickness and the cache is flushed as the batteries begin to charge once more.

Ever seen what happens when the power is out for 'too long', that is long enough for the cache batteries to die? Same problem: ASP gone, reload required. I have seen this multiple times and in one case had strongly warned the customer to get that thing some power, even if it's just 'dirty wall power'. They did not and it was profitable for me. :-)

The problem is that you have x amount of data. The RAID cards have *ZERO clue what that data is, it's just sectors(blocks) of data heading to disk. It hasn't gotten there yet and if the batteries die that data is lost. Now from a RAID perspective, who cares? I mean sure maybe a single sector was actually being written when the lights went off, now that sector is probably in error. Is that enough to kill the system? Not likely, as it can still be rebuilt from RAID.

But let's back up a tick and look at IBM i. It has been madly writing data to that raid card and has been assured that ALL the data IS WRITTEN. That is the point of cache. If the card accepts the write, IBM i comfortably goes about its business as if that data IS on disk and IS valid. And now it's a lie. Mr Raid card says: "Yeah I didn't really deposit the money see, it was in my back seat. I WAS gonna go to the bank in the morning, honestly, and deposit it. But my car was stolen overnight."

So that data is gone. And what was that data? Was it an index update that could be rebuilt? Was it a data update that has your raise in it? Or payment info or EDI shipment data that was transmitted. Or .... The key is that it is UNKNOWN what that data was. Remember IBM i 'wrote it and forgot it'. So given we cannot know what was lost, we must assume all is lost. Its all about data integrity.

- LDrF

I'd love to hear your thoughts about that.

:wq! PoC



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.