Check whether the filesystem appears in the output of
grep -w sync /proc/mounts. Spoiler: the answer is no. Mounting a filesystem with immediate sync is extremely slow. (Also it causes a lot of small writes, which would reduce the lifetime of flash devices.)
Some applications flush the data to disk by calling
fdatasync. The Unix APIs are unfortunately not well-designed when it comes to resilience¹. From an application perspective, some changes need to be resilient, because the application has transmitted data to a remote machine indicating that the change has been saved. In this case
fdatasync is the correct interface. But many applications need something different, namely the guarantee that if they make change 1 followed by change 2 and the system crashes midway, then after restarting there won't be change 2 without change 1. (Example: change 1 = writing a new version of a file, change 2 = deleting the old version.) Filesystems reorder filesystem writes for performance; normally this is invisible to applications, since it's only about what happens between the filesystem cache/buffer and the disk, not about anything that's visible to applications. But in case of a system crash, the disk contents reflect the order of the actual disk writes. There's no API to say “this change must take place before that change”, so applications use
fdatasync as a poor man's fallback (perform change 1, call
fdatasync to make sure it's been propagated to the disk, then perform change 2). This can have a negative impact on performance, especially on media with slow writes such as flash.
If an application is excessively slow on your system due to overuse of
fdatasync or its cousin
fsync, you can use eatmydata to nullify the
fdatasync calls. But beware that if your system crashes in the middle, you may be left with inconsistent data.
I'm not sure whether my answer is relevant to recoll or to changing settings of a Firefox addon. Those operation may well be reading from the disk. Especially recoll — its job is to read a lot of data!
Also, even if changes are not synchronized to disk immediately, you can expect some of the data to be written. If data isn't written to disk, it has to remain in memory, and in the meantime that memory can't be used for other, more useful things. Furthermore, it would be a waste not to keep the disk busy: if there's data to be written, the kernel will start writing it, while the application continues to execute and produce more data.
¹ Resilience, in the context of filesystem design, is the issue of whether a change to the filesystem will be preserved if the system crashes.