×
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.