[hi-v-rocknroll]

More industry experience in real world would've made it clear that they're totally useless for datacenters where there are rarely power outages with many 9's of electrical uptime measured in months or years.

UPSes and BBWC evolved to bring reliability to production gear running in non-DC environments when mainline servers used spinning rust without backup power. Today, it's largely a vendor up-charge.

Write barriers cause far too much latency in practice on servers in tier IV datacenters, so they're almost always turned off except for a tiny fraction of systems.

There has never been a "perfect" or a universal solution, only a risk budget and suitability for a specific use-case.

[jakedata]

Write barriers aren't just for durability - they also can even out major latency spikes when bloated buffers ultimately must be flushed. Database, filesystem, RAID, device, flash management and individual chips all become saturated at some point. Managing performance at the database engine layer gives you visibility into the issue at a high level as opposed to rolling merrily along until commits start taking 2000 ms. As an example, ZFS is terrifyingly unpredictable at high loads.

[ohnoitsahuman]

Can confirm about ZFS - at anything above 85% space utilisation under high load it gets bad on FreeBSD and impossibly weird on Linux.

[otterley]

Power availability isn't the only concern when it comes to taking the risk of async writes. Kernel panics will cause unflushed writes to be lost, and storage hardware can experience gray or total failures, sometimes completely suddenly.