答案1
检查文件系统是否出现在grep -w sync /proc/mounts.剧透：答案是否定的。通过立即同步挂载文件系统非常慢。 （此外，它还会导致大量小写入，从而缩短闪存设备的使用寿命。）
一些应用程序通过调用将数据刷新到磁盘fdatasync。不幸的是，Unix API 在弹性方面设计得不够好。从应用程序的角度来看，某些更改需要具有弹性，因为应用程序已将数据传输到远程计算机，表明更改已保存。在这种情况下fdatasync是正确的接口。但很多应用程序需要不同的东西，即保证如果他们先进行更改1，然后进行更改2，并且系统中途崩溃，那么重新启动后就不会出现没有更改1的更改2。（例如：更改1=编写新版本文件系统，更改 2 = 删除旧版本。）文件系统重新排序文件系统写入以提高性能；通常这对应用程序来说是不可见的，因为它只涉及文件系统缓存/缓冲区和磁盘之间发生的事情，而不是应用程序可见的任何内容。但在系统崩溃的情况下，磁盘内容反映实际磁盘写入的顺序。没有 API 规定“此更改必须在该更改之前发生”，因此应用程序用作fdatasync穷人的后备（执行更改 1，调用fdatasync以确保它已传播到磁盘，然后执行更改 2）。这可能会对性能产生负面影响，尤其是对于写入速度慢的介质（例如闪存）。
如果某个应用程序由于过度使用fdatasync或其同类而在您的系统上速度过慢fsync，您可以使用吃我的数据使fsync/fdatasync调用无效。但请注意，如果您的系统中途崩溃，您可能会留下不一致的数据。
我不确定我的答案是否与 recoll 或更改 Firefox 插件的设置相关。这些操作很可能是阅读从磁盘。尤其是回想一下——它的工作是读取大量数据！
此外，即使更改没有立即同步到磁盘，您也可以预期会写入一些数据。如果数据没有写入磁盘，它必须保留在内存中，同时内存不能用于其他更有用的事情。此外，不让磁盘保持忙碌也是一种浪费：如果有数据要写入，内核将开始写入，而应用程序继续执行并产生更多数据。
1在文件系统设计的背景下，弹性是指在系统崩溃时是否保留对文件系统的更改的问题。