Corruption is an orthogonal issue - losing any amount of data, even a single bit, can lead to corruption. Avoiding corruption by lowering I/O latency is not a

Corruption is an orthogonal issue - losing any amount of data, even a single bit, can lead to corruption. Avoiding corruption by lowering I/O latency is not a viable strategy - at least not given "realistic" latencies and realistic frequency of I/O. In theory - sure, if I/O were once per day, and latency 1ns, you might accept the low chance of corruption without mitigation. In practice, you almost certainly need some concept of atomic actions or transactions to deal will corruption. The more relevant question then isn't whether phones crash and cause corruption, it's whether the additional amount of committed transactions you lose by relaxing durability requirements matters. You're always at risk of losing those in flight - does it matter if you lose the photo you just took? It depends, but I suspect the linked articles fsyncs/second is certainly massively excessive. The "bad" case was after all still just 1/50th of a second, i.e. much less than the blink of an eye. My contention is that phones don't crash often enough to make sub-second durability worthwhile. Most phones I come across certainly crash less than once a day, and losing your past 1 second of actions once a day sounds acceptable to me. In short: the benchmark is not directly useful. Perhaps it correlates with some relevant aspect of I/O performance (but that's not clear), or perhaps software is buggy and actually tries to fsync more than 50 times a second (but then: fix that), but it may simply be a meaningless benchmark.