RAID Cache: Write-Back vs Write-Through and Why Arrays Slow Down
A server that was fast last month and is crawling this month, with no configuration change, no failed drive and nothing in the application logs, is very often a RAID cache problem. The controller has quietly switched its write policy from write-back to write-through, and nothing told anybody.
This guide explains what the two write policies do, why the battery or supercapacitor on the controller decides which one you get, the two situations where the switch happens silently, and how to check your own controllers before someone reports the server is slow.
What the cache is doing
A hardware RAID controller has its own memory, typically between 512MB and 4GB. That cache sits between the server and the disks and does three things: it absorbs bursts of writes so the application is not waiting on spinning disks, it coalesces many small writes into fewer larger ones, and it reorders writes so the drives do less seeking.
On a parity array the third job is the important one. Every small write to a RAID 5 or RAID 6 set requires reading the old data, reading the old parity, computing new parity and writing both back, which is the read-modify-write penalty. Cache lets the controller gather enough writes to compute parity across a full stripe and avoid most of that work. Remove the cache and the penalty arrives in full.
Write-through
In write-through, the controller does not tell the operating system a write has completed until the data is actually on the disks. The cache still helps reads, but every write waits for physical media.
It is completely safe. If power fails mid-write, nothing was acknowledged that had not been written, so the array is consistent.
It is also slow, and on a parity array with a random write workload it can be several times slower than write-back. Sequential writes suffer far less, which is why the same policy change can be barely noticeable on a backup target and catastrophic on a database.
Write-back
In write-back, the controller acknowledges the write as soon as the data is in its own cache, then destages it to the disks in its own time. The application stops waiting on disk latency.
This is where the performance comes from, and it is why every enterprise controller ships with the capability. But it introduces a window in which the server believes data is safely stored and the disks do not have it yet. If power is lost in that window, and nothing protects the cache, that data is gone and the array may be inconsistent.
That is why write-back requires cache protection. Without it the controller will refuse to enable write-back, or will warn you loudly if you force it.
How the cache is protected
Two approaches, and it is worth knowing which your controller uses because they fail differently.
A battery backup unit is the older method. A rechargeable battery holds the cache contents alive until power returns. It works, but batteries have a service life of a few years, they degrade with heat, and they need periodic relearn cycles to keep their capacity reading accurate.
A supercapacitor with onboard flash is the modern method, sold under names such as CacheVault, FBWC and similar. On power loss the supercapacitor supplies just enough energy to copy the cache contents into non-volatile flash on the controller. Once written, the data survives indefinitely rather than for a battery's worth of hours. Supercapacitors also last longer and tolerate heat better.
Our guide on identifying RAID controllers, cache modules and batteries covers telling which module you have and which are interchangeable.
The silent slowdown, part one: a failed battery
Here is the behaviour that causes the mystery. When the battery or supercapacitor fails, the controller does not stop. It protects your data by dropping from write-back to write-through automatically.
That is the correct engineering decision and it is also completely invisible from the operating system. No error is raised to the application. No disk has failed. The array is healthy and optimal. Everything works, just several times slower on writes.
Meanwhile the users report that the system got slow, and the investigation goes to the database, the network and the virtualisation layer before anybody opens the storage controller. We have seen weeks spent on this. Our guide on the Dell PERC H730P covers the same failure on that specific controller, and the HPE Smart Array P440ar covers the HPE equivalent.
The silent slowdown, part two: the relearn cycle
Battery-backed controllers periodically discharge and recharge the battery to recalibrate its capacity reading. This is the learn or relearn cycle, and it typically runs on a schedule measured in weeks or months.
During the relearn the battery cannot guarantee protection, so the controller drops to write-through for the duration. That can be several hours.
This is the source of the classic complaint that the server is slow on the first Monday of the month, or slow overnight once a quarter, with no other pattern. It is not a fault. If the timing is bad, the relearn schedule can usually be moved to a quiet window, which is worth doing before someone opens a performance investigation instead.
The other cache settings
Read policy. Read-ahead pre-fetches data the controller expects to be requested next, which helps sequential workloads and wastes cache on random ones. Adaptive read-ahead tries to detect sequential patterns and switch by itself. For a random workload, no-read-ahead leaves more cache for writes.
Drive cache policy. Each physical drive has a small write cache of its own, and the controller can enable or disable it. Enabling it adds another unprotected window that the controller's battery does not cover, because it is inside the drive. The default of disabled is the right one unless you have a specific reason and understand the exposure.
Forcing write-back without protection. Most controllers let you do it, usually labelled something like force write-back with no battery. It is the correct choice for a scratch volume, a render cache or a test box where the data is reproducible. It is a poor choice for anything you would be upset to lose, and a UPS is not an equivalent safeguard because it does not protect against a power supply failure, a tripped breaker inside the rack or someone pulling the wrong cable. Our guide on UPS sizing and power protection covers what a UPS does and does not cover.
When you want no cache at all
If you are running ZFS, Storage Spaces, vSAN, Ceph or any software-defined storage layer, the hardware cache is not an asset. Those systems manage their own consistency and expect direct access to drives, and a controller sitting in between with its own write cache can defeat the guarantees they are built on.
For those platforms you want an HBA in IT mode, which presents drives directly and has no cache to worry about. Our guides on RAID controller versus HBA in IT mode and the LSI 9207-8i cover the distinction and what you give up.
What to check on your own servers
Confirm the current write policy on every array, not the configured one. Controllers report both the policy you set and the policy currently in force, and the gap between them is the whole point.
Check battery or capacitor health and age. Anything past three or four years on a battery-backed controller should be treated as a replacement candidate rather than a surprise.
Put the current write policy into monitoring. This is the fix that stops the problem recurring. A check that alerts when an array falls back to write-through turns a multi-week investigation into a ticket. Our guide on hardware monitoring covers what else belongs alongside it.
Take a baseline while things are good. Without one, nobody can say whether the array is slow or just always was. See measuring storage performance.
Sourcing
We supply RAID controllers, cache modules, batteries and supercapacitor packs for Dell PERC, HPE Smart Array, LSI and MegaRAID platforms, along with HBAs for software-defined storage. If a controller has dropped to write-through and you need the right battery or cache module, send us the controller model or the server service tag and we will match it before you order. Request a bulk quote or email sarah.jane@techsellerusa.com.
Common questions
What is the difference between write-back and write-through?
Write-through acknowledges a write only once the data is physically on the disks, which is completely safe but slow. Write-back acknowledges as soon as the data is in the controller's cache and destages later, which is much faster but creates a window where acknowledged data is not yet on disk. That window is why write-back requires a working battery or supercapacitor protecting the cache.
Why did my server get slow with no configuration change?
A failed RAID cache battery is one of the most common causes. When the battery or supercapacitor fails, the controller automatically drops from write-back to write-through to protect your data. No disk has failed, the array reports as healthy, and nothing surfaces to the operating system, but writes are now several times slower on a parity array. Check the controller's current write policy before investigating the database or the network.
Why is the server slow only once a month?
That pattern usually points to the battery relearn cycle. Battery-backed controllers periodically discharge and recharge the battery to recalibrate its capacity reading, and during that cycle the cache cannot be guaranteed, so the controller temporarily drops to write-through. The slowdown can last hours. It is not a fault, and the schedule can normally be moved to a quieter window.
Is it safe to force write-back without a battery?
Only where losing recent writes is acceptable, such as scratch volumes, render caches or test systems whose data can be regenerated. For production data it is not safe. A UPS is not an equivalent protection, because it does not cover a power supply failure, a breaker tripping inside the rack, or a cable being pulled. If you need write-back performance on production data, replace the battery or cache module rather than forcing the setting.
Should I enable the drive's own write cache?
Usually not. Each drive has a small write cache of its own, and the controller's battery or supercapacitor does not protect it, because it sits inside the drive rather than on the controller. Enabling it adds a second unprotected window in exchange for a modest gain. The common default of disabled is the right choice unless you have a specific reason and accept the exposure.
Do I need cache if I am running ZFS or vSAN?
No, and a hardware cache can actively work against you. Software-defined storage layers such as ZFS, Storage Spaces, vSAN and Ceph manage their own write consistency and expect direct access to the drives. A RAID controller with its own write cache sitting in between can undermine the guarantees those systems are built on. For these platforms, use an HBA in IT mode, which presents drives directly and has no cache.
If an array has fallen back to write-through, send us the controller model or service tag and we will identify the right battery or cache module.
