3 ms·

Those VM tunables are about dirty OS cache, not dirty drive cache. If you fsync() a file on Linux it will be pushed to the drive and (if the drive does not have

Those VM tunables are about dirty OS cache, not dirty drive cache. If you fsync() a file on Linux it will be pushed to the drive and (if the drive does not have battery/capacitor-backed cache) flushed from drive cache to stable storage. If you don't fsync() then AIUI all bets are off, but in practice the drive will eventually get around to flushing your data anyway. The OS has one timeout for cache flushes and the drive should have another one, one would hope.

shivak 5y ago
As you noted, Apple's fsync() behavior is defensible if PLP is assumed. Committing through the PLP cache isn't how these drives are meant to operate - hence the poor behavior of F_FULLSYNC. But this isn't specific to Macs and iDevices. Some non-PLP drives also struggle with sync writes on FreeBSD [1]. Most enterprises running RDBMS mandate PLP for both performance and reliability. I understand why this is frustrating for porting Linux, but Apple is allowed to make strong assumptions about how their hardware interoperates. [1] https://www.truenas.com/community/threads/slog-and-power-loss-protection.89602/post-620237 https://www.truenas.com/community/threads/slog-and-power-los...
- marcan_42 5y ago
  There is no PLP. If you yank power you lose up to 5-10 seconds of disk cache (fsynced files that weren't F_FULLFSYNCed). I tested this. On macOS.
  - shivak 5y ago
    I guess we expected a marvelous interplay of hardware and software, but all we got was fudged numbers.
DooMMasteR 5y ago
On my Linux (at least to my SATA drive) fsync() issues a "FLUSH_CACHE" to the drive too.