How long can file system writes be cached with ext4?

Solution 1:

You can set the commit interval to a custom value which, I believe, can be as high as a 32-bit unsigned integer number of seconds; so about 4 billion seconds, or 136 years. This is available through the commit mount option, which you can place into effect as follows (this is merely an example; you can also set this in fstab):

mount /dev/sda1 -t ext4 -o rw,data=writeback,nobh,commit=12345678

The commit interval is not based on any type of condition like whether the data is appended or overwriting existing data or whatever. The commit mount option (which defaults to 5 seconds if you don't supply the mount option at all) is equivalent to doing something like this in a bash shell:

#!/bin/bash
while :
do
    echo "Syncing all uncommitted data and journal to disk"
    sync
    sleep 5
done

Don't confuse data=ordered and this global filesystem sync interval ("commit interval" is perhaps a less meaningful term for those of us who understand the functionality of the command line program sync, in which case it may be better named the "sync interval"). data=ordered is about the order in which data and metadata are updated (where data=writeback is "less safe / faster" and data=journal is "more safe / slower"). commit=12345678 is about the frequency with which the filesystem driver itself forces a FULL sync of ALL dirty data/journal/metadata/whatever to the physical media. And you can most certainly set it to 136 years if you want, and mount with data=writeback,nobh and programs that don't call fsync() or sync() will have dirty pages sitting in RAM for... several lifetimes.

Update: Based on your context in your question edit, I'd say that you should run your filesystem with mount options data=journal,commit=1 or even with the sync mount option, until you are able to resolve your graphics driver kernel panics. This will maintain maximum data integrity but at the cost of performance. You'll especially want to do this if you are frequently writing data to disk that you can't afford to lose, and that's doubly important if you don't "trust" the apps you're using to employ fsync() appropriately.

Source: here and personal experience

Solution 2:

Whatever the answer to your question is, it doesn't matter.

The guaranteed exposed behavior of the ext4 filesystem is that "data will be on disc after a successful sync/fsync call". So, if you have an application which makes you ask this question, you should insert synchronization calls at the critical points where data integrity needs to be ensured. If you're a user worried about the same issue, you can call the sync command-line utility before doing whatever dangerous behavior might cause an unclean shutdown.