@joshbot, good question. I was checking an RPi I have here and the filesystem type seems to be ext4:
/dev/mmcblk0p6 on /mnt/data type ext4 (rw,relatime,data=ordered)
sync option you mentioned, if active, would be shown in the option list in brackets above. I was searching the web and found a few posts that suggest that the sync/async option doesn’t actually apply to ext4, though:
The following options apply to any filesystem that is being mounted (but not every filesystem actually honors them - e.g., the sync option today has effect only for ext2, ext3, fat, vfat and ufs):
async All I/O to the filesystem should be done asynchronously.
sync All I/O to the filesystem should be done synchronously. In case of media with limited number of write cycles (e.g. some flash drives) “sync” may cause life-cycle shortening.
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). This default value (or any low value) will hurt performance, but it’s good for data-safety. Setting it to 0 will have the same effect as leaving it at the default (5 seconds). Setting it to very large values will improve performance.
So for ext4, it sounds like that “commit” option applies. But perhaps the right approach in this case, instead of changing the fs mount options, is for the application (sqlite db) to use the fsync system call in its own implementation, when the it has completed a db transaction, for example. Have a look at this sqlite “pragma shcema.synchronous” setting:
My gut feeling is that that’s the way to go, to achieve both performance and reliability: configuring sqlite to sync writes to disk at the strategic points, and letting ext4 be async.