IBM Support in Switzerland After End of Life

A Performance Collapse With No Fault Behind It

An IBM Storwize array becomes dramatically slower on writes. Every health view is green, no component is failed, no alert has been raised, and the storage team can honestly report that nothing is wrong. The application team is equally honestly reporting that something is badly wrong. Both are correct.

The System Traded Speed for Safety

Write caching is only safe while the battery in the node canister can guarantee that cached writes survive a power loss. When the battery can no longer make that guarantee, the system disables write caching and reverts to write-through, committing every write directly to disk. That is exactly the right decision and it is a deliberate protective action rather than a failure.

Which Is Why It Is Reported Where Nobody Looks

Because it is not a fault, it appears as an informational event about caching state rather than as an alert, and array health remains perfect. An array running write-through is indistinguishable from a healthy one in every summary view. The way to find it is to check the caching state of the managed disks specifically, which is not part of any routine health check.

An Inexpensive Component for the Performance It Restores

The battery is among the cheaper parts in the enclosure and it governs the single largest performance characteristic of the array. ICD tests remaining capacity before dispatch rather than confirming only that a unit is present, and supplies Storwize and Power components for generations past IBM end of support, covered for one to three years.