A  while ago I migrated my /home LVM volume to the new (experimental) btrfs in order to take advantage of snapshots for backup. Despite my overall satisfaction with btrfs in terms of usability and features, it turned out that there is one major issue with applications making excessive use of fsync(3). The symptom of this issue is a high latency to user-actions while data is being written to disk. The impact on my system was especially high with liferea, my news feed reader. It was completely unusable while fetching data or marking a batch of items as read.

After some investigation I found eatmydata, which basically replaces all calls to fsync(3) with it's own implementation, which just returns without doing anything. On Debian, it can be installed directly from the archives:

aptitude install eatmydata

It offers a small binary which can be used to bootstrap other applications to use the variant of fsync(3) provided by eatmydata instead of glibc. This is how I use it right now to start liferea:

eatmydata -- liferea

There are of course drawbacks and risks of using eatmydata. The purpose of fsync(3) is to ensure that data is safley written to a disk before going on with the work-flow inside an application. Effectively discarding those calls to fsync(3) exposes an application to potential data-loss! As liferea does not handle data for which I depend on integrity, I can cope with the risk of losing it but I would never ever use it on critical applications!