5 ms·
I have been running Firefox for a long time with an LD_PRELOAD wrapper which turns fsync() and sync() into a no-op. I feel it's little antisocial for regular d
by zbuf 10y ago
I have been running Firefox for a long time with an LD_PRELOAD wrapper which turns fsync() and sync() into a no-op.
I feel it's little antisocial for regular desktop apps to assume it's for them to do this.
Chrome is also a culprit, a similar sync'ing caused us problems at my employer's, inflated pressure on an NFS server where /home directories are network mounts. Even where we already put the cache to a local disk.
At the bottom of these sorts of cases I have on more than one occasion found an SQLite database. I can see its benefit as a file format, but I don't think we need full database-like synchronisation on things like cookie updates; I would prefer to lose a few seconds (or minutes) of cookie updates on power loss than over-inflate the I/O requirements.
- jstimpfle 10y ago> I have been running Firefox for a long time with an LD_PRELOAD wrapper which turns fsync() and sync() into a no-op. For completeness, this is probably the eatmydata command.
- robbles 10y agoWould you be willing to post a how-to or example of doing this? I'm curious about how this trick works!
- necessity 10y agoIt's probably best to just disable sessionstore if you don't want it, as overwriting fsync would disable it for all operations Firefox might use, not just sessionstore.
- zbuf 10y agoThat's exactly what I wanted to achieve; I didn't have the time or inclination to work out exactly which part of Firefox is responsible. In my case it was not SSD wear I wanted to reduce, but the short pauses during interactive use.
- zbuf 10y agoTake a look at libeatmydata. I'm doing something practically identical
- Yoric 10y agoIf my memory serves correctly, Session Restore doesn't use sync()/fsync() at all. Edit Double-checked in the code: I'm right, it doesn't. Edit If you're interested in how Session Restore improves the safety of its writes without using sync()/fsync(), the details are on my blog: https://dutherenverseauborddelatable.wordpress.com/2014/06/26/firefox-the-browser-that-has-your-backup/ https://dutherenverseauborddelatable.wordpress.com/2014/06/2...
- quotemstr 10y agoSo you're relying on the implicit write barrier many filesystems supply that ensures that the contents of a file hit the disk before a renaming of that file does. That's adequate, but I'd personally checksum the file instead of relying on corruption causing JSON to become structurally invalid.
- Yoric 10y agoWell, it's better when this write barrier happens (which is not true on ext4, iirc), but we rely mostly on the the fact that operating systems flush automatically within 20 seconds (I don't remember the actual numbers, but I'm almost sure it's actually within at most 5 second in practice). Checksums/signatures would be more precise, indeed.
- icebraining 10y agoI don't think the use of SQLite is a problem, since it can be configured to be very careful or very reckless. http://www.sqlite.org/pragma.html#pragma_synchronous http://www.sqlite.org/pragma.html#pragma_synchronous
- zbuf 10y agoIt's a problem if it's not configured appropriately. Remember the use of SQLite is entirely internal to the application; it's not for users to know how it's used, or even that it's used at all. In the case of a Chrome (many versions ago; may have changed), we manually tweaked that pragma in all our users profiles. I recall something like an order of magnitude reduction of pressure on the /home server.