Hacker News Reader

Comment by charleslmunger | Hacker News Reader

The behavior of fsync is a battle of OS developers and OEMs versus application and database developers. Gaming the implementation of fsync to do less than fully fsync makes benchmarks look amazing, improves user perceived latency, and reduces flash wear. On the other hand, it corrupts data - but that's rare, "the hardware is failing anyway", etc.

That's how you end up with stuff like OS X's "no really, fsync" param [1], or Motorola shipping nobarrier on their phones. [2]

[1] https://github.com/google/leveldb/issues/203#issuecomment-55...

[2] http://taras.glek.net/post/Followup-on-Pixel-vs-Moto:fsync/

View on HN

My CPU can't isolate processes due to Intel cutting corners with speculative execution.

My memory is vulnerable to row hammer due to vendors cutting corners while pushing for increased DRAM density.

And my - supposedly - non-volatile storage is broken due to vendors gaming benchmarks with fsync.

Is there any component in a modern consumer computer that isn't fundamentally broken in one way or another?

No. At most these components are as reliable as random noise allows them to be. That part is just physics.

That off switch in your PSU is a conceptually sound implementation. Not the one at the front, that's broken too.

What you call "broken" others call "performance choices". Except SSD controllers, they are big fat phonies.

Look at how much slower CPUs are without those speculative execution tricks. I can buy gigabytes of RAM with a 20 I found in an old jacket. You can explore entire worlds consisting of gigabytes of high res textures and mesh data in near real-time, while downloading 4 new albums off the internet.

Broken?

> Look at how much slower CPUs are without those speculative execution tricks.

But do I care? All my computers, except the really ancient phone I use, are snappy.

Of course there are cases were CPU speed matters, but I don't know if they are any less obscure than the cases where timing attacks are a risk.

> Broken?

Yes, it is breaking the promise of what it is supposed to do. If fsync() was defined as "will ensure your data is on disk, unless that's kinda slow, then who knows", then the behaviour would not be broken, just potentially useless for many applications. But if you promise to ensure something is stored on disk, and then don't, that's the definition of being broken.

This. It's like those counterfeit memory cards you could get on eBay, that had a 128 Mb chip but reported themselves as 8 Gigs or so. "Works perfectly if you stay below 128 Mb!"

You're welcome to go back to 486 class machines with 32 megs of RAM and IDE disks. I'll take the performance optimizations.

Reply on news.ycombinator.com