If empathy is run on a system with the user's home on a btrfs partition, tp-logger is using (f)sync (or whatever, I did not dig to deep into it), that the system became unusable.
The logger calls those functions when a message is received or sent: fopen/fseek/fprintf/fclose Those are standard libc function, fclose might be syncing file to disk which is a legitimate use. I strongly doubt that the logger is responsible for making btrfs unstable, but I would have a look at traces from the logger (could be debug traces using TPL_DEBUG=all, or straces showing abuse of sync system call) if you take the time to provide them. Also, mentioning logger version and step to reproduce is important in bug reports, please consider providing those for any further reports on any projects.
I should also have mentionned that there is some cache code using SQLite, which might do sync call, in which case you would have similar issues with projects like Evolution, Firefox, etc. But in this case, you would have better luck asking the SQlite dev, if it's not already reported.
I am actually no expert on btrfs, I just noticed this behavior when migrating from ext3 to btrfs. And you are correct: Firefox also suffered and became slower, but this got fixed/became better somehow.
It seems as if this was fixed by btrfs/sqlite or youself? :) as this problem does not appear on F16 beta rc4 anymore. I hope closing is in your interest too :)
I swear I didn't change anything on my side ;) People from tracker uses a set of SQLite pragmas to mitigate this, if you experience this issue again, let me know, it's still possible to consider adding those pragmas.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.