ext4linuxraidstorage
It seems to me that data=journal prevents file system inconsistency in the case of power failure. Using it with a dedicated journal device mitigates the performance penalty of writing the data twice. A power outage would still lose the data that is currently being written to the journal, but the file system on disk would always be consistent.
If that amount of loss is acceptable, is a RAID controller with battery backed cache really worthwhile?
I've worked in building a system for automation on boats, and there was a prerequisite: in every moment the power could go down and everything must boostrap again correctly.
My solution was to build a Gentoo-based initramfs system, with only a rw folder for application and configurations (this is the approach used by every router/firewall vendors). This solution add an additional layer of complexity when dealing with system upgrades, but assure you that the system will ALWAYS boot.
Regarding your specific question, you should keep EXT4 journal enabled for having faster fsck (of a few secods), use the data=journal mount option, lower the commit option or use sync option to keep buffers always empty.
Refs: http://www.kernel.org/doc/Documentation/filesystems/ext4.txt
You're over-thinking this.
Of course, this depends slightly on the manufacturer's specific implementation, but having deployed thousands of HP ProLiant servers over 10 years, I've experienced hundreds of RAID controller battery failures. I replaced the bad units, knowing that sudden power-loss or a system crash would result in some level of data corruption if I didn't have a healthy battery in place.
I was happy to see the move to flash-backed write caches in recent years. The flash units on HP ProLiant systems are a separate super-capacitor that attaches to the controller RAM module. I suppose they can fail. I've not experienced one yet. The HP Smart Array RAID controllers can be set to keep write caching enabled regardless of the battery/supercap health. This presumes facility protection against sudden power-loss. You still have to worry about application stability and system crashes.
It sounds as though you're referring to Dell PERC controllers and their NVCACHE implementation. It's a similar design. Dell explains in their guidebook...
4.5.1 Non-Volatile Cache
Dell PERC controllers with non-volatile (NV) cache use the standard battery as contained in the Dell
PERC controllers with a battery back-up unit (BBU). The difference is in battery implementation:
- The battery in the BBU offering retains the data in cache in the event of a power cycle for a
guaranteed period of 24 hours (typically up to 72 hours).
- The battery in the NV cache offering will transfer the data from cache to flash in the event of
a power cycle, where the data will be retained for up to ten years.
Think about your application and your storage access patterns. Are you really writing to the array fast enough and with an amount of data that cannot be flushed to disk effectively? Is your application unable to recover from a crash or sudden reboot?
If you're really concerned about application availability, focus on protecting facility power (healthy UPS + generator) and bolstering your systems with redundant components (power supplies, fans, etc.)
Edit:
I'm looking at an HP Smart Array P410 RAID controller with a flash-backed write cache onboard. There are health LEDs for the flash module and the older external battery (HP equipment doesn't do the relearn cycle).
A dedicated battery microcontroller continuously monitors the HP Smart Array battery pack for signs of damage, including an open battery terminal, partial battery short, charge timeouts, and over discharge conditions.
For the super-capacitor, its health is monitored, but the LED indicator is located on the flash module. The RAM is ECC error-correcting, so that's also another level of defense. Both are reported to the host server, via SNMP traps and can be viewed through diagnostic utilities.
From HP's Smart Array technology guide.
The Super-cap sub-assembly consists of two 35-Farad 2.7V capacitors, configured in series, providing 17 Farads at up to 5.4V. The charger maintains the Super-cap at 4.8V, providing the required amount of power to complete backup operations while extending the life of the Super-cap. The charger monitors Super-cap health and activates LED indicators on the FBWC module to warn of impending failure. The Super-Cap module uses the same form factor and housing as the HP 650 mAh P-Series battery used in the HP BBWC.
My point with all of this is that the manufacturers have engineered solutions to make the flash cache solution work and become a viable replacement for the older battery-based technology. It's in their interest to provide proper monitoring facilities.
As a note, check the visual indicators for the HP's newest-generation flash-modules. You can be sure that all of these checks are integrated into the alerting and diagnostics system for the controller.
Best Answer
A battery backed cache does more than just keep your filesystem consistent in the event of a power-failure. The cache itself actually performs read caching, and to some extent write-caching (mostly just re-ordering the writes for better write performance). Having a cache on your RAID controller can be a significant speedup for performance. Having a persistent cache of some kind (be it battery-backed, or the newer flash-backed caches) just makes sure that uncommitted writes don't get lost when things go kablooie.