On Tue, 10 Apr 2012, Toby Corkindale wrote:
On 10/04/12 16:44, Tim Connors wrote:
(if you can't tell, I have a pet hate for people that insist fsync() is the only true way to ensure data integrity. Use a reliable filesystem instead!)
Soooo.... if you aren't using fsync(), then what happens if you write() to a file, say your database of orders, then write to the HTTP socket to tell the user their order went through, and then you have a power failure ten seconds later, before the operating system has got around to flushing that data to disk?
Sure. You're doing transactions. Do transactions properly. Probably outside of a filesystem alltogether - put your database on a raw block device.
What if my desktop or mozilla have just updated a config file and then the power fails? Should I have to wait 40 seconds in which the entire system activity freezes, and I have no gaurantee which version I get, or should I have to wait no time at all and have no guarantee which version I get? As long as it is atomically renamed either way, I'll happily go with the version that doesn't unnecessarily spin up my spundown disks, and doesn't cause me to wait for something unimportant to happen.
I have a SATA disk in my laptop with 4G of SSD onboard as a cache. It can stay spun down for a while even if writes are done - no need to spin it up again until the cache is nearly full. I'd be focussing more on your storage medium than your filesystem. The problem with omitting the fsync in the case of an application is that you are violating your contract with the user. If I save a document then when the application says that the save is complete my document had damn well better be on my memory stick. v1.0 of AmigaOS was a classic example of this - it would indicate that a disk operation was complete and tell the user they could eject the disk while it was still writing the final few sectors - someone forgot the (AmigaOS equivalent of) fsync(). OTOH, sticking fsyncs everywhere in your code just because it seems like a good idea is to be frowned upon... James