1

I noticed that an indexing engine on my system, recoll uses a lot of disk when it is working, and that there was disk activity any time I changed a setting of a Firefox addon. I don't know whether those applications are designed to sync changes immediately to disk, or if it is due to some setting in the systems configuration.

Is there a way of finding out.

PS. I left a question on Software Recs about recoll/xapian issue.

3

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 fsync/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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.