Too much of the storage industry has been consumed by the performance at any cost metric. Even when that means making engineering decisions that put data at ris

Too much of the storage industry has been consumed by the performance at any cost metric. Even when that means making engineering decisions that put data at risk. Back when the original POSIX specs were being worked on, a common assumption was that anyone serious about their data ran all disks/raid controllers/filesystems/etc in writethrough (or equivalent) mode. Combined with what the spec doesn't guarantee leaves us in a world where its pretty much impossible to really make any data retention guarantees. A large part of this is that write() style api's should never have been allowed to be anything but synchronous with the data being commited to non-volatile storage. Thats because if you move the error handling to when fsync() or close() (or pick your place) if one of the writes fails its impossible to report accurately to the application what failed sufficiently to know how to recover it. This goes beyond just filesystems these days, there is a major raid chipset vendor that is/was shipped by a couple tier 1 vendors which only ran in write-through/FUA mode if it wasn't provided a battery, the performance was so abysmally bad that nearly everyone ended up buying the battery to enable write back. The problem with this controller in write back mode is that it didn't honor any kind of fencing or FUA when in writeback mode, instead depending on a intermittent timer flush based system to force the data to disk. If there was a disk failure on write, it was impossible to know what had actually been flushed and depending on firmware it would go from either reporting the error to silently dropping the data. Neither helps the end application that might have quit, and had definitely passed its close/rename/flush/etc sequences by the time the error occurred. Bottom line, there is an API mismatch from top to bottom of the storage stack. Starting with the simple idea that if a filesystem operation doesn't provide an async completion notification it should be forced to be consistent at completion. Anything else _WILL_ create the opportunity for data loss over even simple power loss, much less the more complex cases of delayed writes in raid controllers/async replication/etc. Put another way, like this article points out and others linked here reference, there are a ton of "bugs" in most OS's storage stack. Enough that they generally behave badly in the face of actual failures.