How do filesystem "commit interval" options interact with
vm.dirty_expire_centisecs? What happens when one is shorter than the other? Does it ever make sense to set these differently?
My understanding is that filesystem commit interval settings control how often the filesystem will proactively write dirty data and metadata to disk, even when
fsync hasn't been called by the application.
vm.dirty_expire_centisecs seems to have a similar role, but at the VM layer rather than the filesystem layer.
Ext4 can be told to sync all its data and metadata every 'nrsec' seconds. The default value is 5 seconds. This means that if you lose your power, you will lose as much as the latest 5 seconds of work (your filesystem will not be damaged though, thanks to the journaling).
Set the interval of periodic commit. Higher values defer data being synced to permanent storage with obvious consequences when the system crashes.
Note, I'm leaving out XFS for now, as its
fs.xfs.xfssyncd_centisecs option appears to apply to metadata only.
This tunable is used to define when dirty data is old enough to be eligible for writeout by the kernel flusher threads. It is expressed in 100'ths of a second. Data which has been dirty in-memory for longer than this interval will be written out next time a flusher thread wakes up.