3 ms·
You're still going to often wait for the file to be written to the disk since many apps care about running sync() in the right places. With tmpfs you don't have
by viraptor 2y ago
You're still going to often wait for the file to be written to the disk since many apps care about running sync() in the right places. With tmpfs you don't have to wait.
- rwmj 2y agoThis is a fair point, but also an indication (again) that the sync primitives in posix are poorly designed. It should be possible to indicate that a file is a temporary and/or can be recreated from scratch. (O_TMPFILE isn't that)
- viraptor 2y agoSync is not only about persistence, but also actual synchronisation. If you're writing to two files and want to ensure ordering, you have to (f)sync - doesn't matter disk or ram.
- rwmj 2y agoI'm pretty sure that's not the case unless you're synchronizing across kernels (eg. NFS close-to-open sync). Although it's true that sync primitives for network filesystems are also a mess.
- viraptor 2y agoBlock devices and their drivers are free to reorder writes in absence of explicit synchronisation. The filesystem level is supposed to take care of keeping things from breaking. I would suspect that tmpfs itself prevents any reordering... but I wouldn't bet on it. Non-memory devices will happily reorder.
- rwmj 2y agoSure, but this is only important if you're working across kernels (or need correct persistence across a crash+reboot, which is "across kernels in time"). Within a single kernel instance, two processes do not need to think about such synchronisation, or else just about all software written would be broken.