Making sure filesystems are mounted with sync

Product support
1

Hi,
For our use case of the Balena Fins, sometimes there will be power outages. It is therefore important that data is written to the disk as soon as possible, rather than cached. I know in Linux normally this involves making sure that the filesystems are mounted with the “sync” option. It is important for us that /data is mounted with sync option enabled.

With the Balena, how can I go about settings this up? I know Balena OS does not have things configured in a conventional manner like most Linux distros, so the options for filesystems are not all in /etc/fstab like they normally are (only /, /proc, /dev/pts, /run and /var/volatile are in there). Or is it already mounted with sync enabled?

3

Hello, anything written by the OS is written in a durable manner, so updates and state changes are guaranteed to not cause corruption. Is what you ask about ensuring writes from your application are also durable?

5

Hi @dfunckt, yeah, there are sqlite databases being written

15

@joshbot, good question. I was checking an RPi I have here and the filesystem type seems to be ext4:

$ mount
...
/dev/mmcblk0p6 on /mnt/data type ext4 (rw,relatime,data=ordered)
...

The 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:

https://linux.die.net/man/8/mount
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.

https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
commit=nrsec
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:

https://www.sqlite.org/pragma.html#pragma_synchronous

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.