The entire reason why all of these cache toggles / batteries / PLP SSDs exist, is to ensure that the OS has full control and knowledge of when data is written permanently to the disk.
So if you have a battery backed RAID, for example. Then theoretically, as soon as data is written to the cache, it can be considered permanently written to non-volatile medium. That is because: If the power fails, the battery will kick in and ensure that the data will be written to the disk (eventually).
The problem with consumer drive caches is that they are not battery backed (unlike a RAID). So let's say that you have no RAID and a plain old consumer SATA SSD. What happens if the OS writes some data to it (which would go into the cache first) and then the power fails before the cached data could be written to the disk? The data could very well be lost, depending on the timing of things.
In order to prevent this issue, software-based techniques exist to ensure data consistency for such drives. For example, write barriers and journaling file systems. In essence, when the OS wants to make absolutely sure that the data that it wrote to the disk is saved onto its non-volatile medium, it will issue a special flush command. The flush (aka fsync) command will write everything in the cache to the disk before returning a successful completion. Apps and the OS use these fsyncs as a "write barrier". And combining that with other techniques like journaling, they can safely recover your file system or database in the case of a power failure to a 100% known good state even if you have no UPS or battery backed drives. There is a performance overhead for doing all of this, but it is 100% necessary to ensure data integrity for non-RAID consumer drives.
So now that we understand how drives work without a RAID, let's consider what happens when we plug this consumer-level drive into a RAID which has its own cache and battery backup (in addition to the cache on the drive). The first thing to consider is, what do the OS and apps do when they see such a RAID? Properly designed systems will recognize that there is no volatile cache present on this virtual RAID disk. And thus, there is no need to perform flushes (i.e. they will disable write barriers), as every byte written to the drive is considered persistent as soon as it hits the controller. So there is now less performance overhead for running database systems (particularly for journaling operations), and your file systems will also be faster.
But what about the actual disks that comprise the battery backed RAID? Do we need to worry about their write caches? Absolutely! It is extremely important to make sure that when the controller writes data to the actual disk, that it is persisted to a non-volatile medium. If it's not, then the entire guarantee that the controller gave to the OS (that the bits written to its cache are safe and persistent) breaks down! This means that your storage subsystem is not functioning correctly and your data is at risk.
So in short:
If you have a battery-backed RAID:
- If the drives part of the RAID are consumer drives, and have a cache (which most do). That on-disk cache absolutely MUST be disabled.
- If the drives are enterprise drives with PLP (power loss protection), then the cache can be enabled, as the drives will ensure that any data written to the drive's cache will be persisted to the non-volatile medium.
I don't want to introduce the concept of a UPS here because: From my point of view, a UPS's job is not to ensure the data integrity of the bits on your disks. It is there to offer some extra time for your apps to perform some work before safely shutting down. And, of course, it can also protect your disks in the case of a misconfiguration. But I think it is incorrect to rely on your UPS to take the place of other technologies that are designed specifically for this purpose, such as write barriers, journaling, FBWC, PLP drives, etc...
This is as best as I understand how this entire system works.