3 ms·
Fair enough :) There's the problem of badly designed APIs, and there's the problem of crap hardware that lies to you. IME, it's difficult to ensure that data
by mangamadaiyan 4y ago
Fair enough :)
There's the problem of badly designed APIs, and there's the problem of crap hardware that lies to you.
IME, it's difficult to ensure that data "written" to disk has actually reached the disk, without disabling the drive's cache. This was true even with spinning rust, and continues to be true with SSDs. I'd rather not get started on read-after-write, with inline checksums in order to verify that your disk isn't lying to you.
In an ideal world, we'd have both well-designed APIs as well as hardware that isn't crap. If I had to choose between the two, I'd go with good hardware, because the API problem can at least be worked around - albeit with a significant investment in time, effort and pain.
I feel your pain, and wish you good luck in your efforts.
- josephg 4y agoThanks! But as for the two problems (bad APIs and bad firmware on SSDs), we should do both! Personally I don't have influence over my solid state devices, but linux is opensource. We should absolutely fix linux to have better APIs here, even if the underlying devices lie sometimes. It might even help with the firmware. The reason for SSDs to lie about flush commands is so they look better in benchmarks. If linux had a better API (with barriers, write groups, transactions, whatever), then benchmarks would probably depend less on fsync. Maybe, eventually, we can solve that problem too.