fsync writes very slow

[Reiner Lange]

I have the following general setup:

Disklayout:
Two HDDs.
One SSD.

Three Physical LLVM Volumes. One for each Disk.
Most stuff is on the HDDs inside LLVM Volumes.
Each mountpoint uses btrfs as raid1 over two LLVM Volumes, located on booth HDDs.

For fast dataaccess, I have btrfs still as raid1 over two LLVM Volumes, but located on the SSD (raid1 is used to protect against data corruption, not disk failure)
Some LLVM Volumes are encrypted with luks.

LXC:
A genkernel with everything enabled for lxc.
Multiple LCX Instances one of which is the Desktop. The root instance does only contain stuff to manage lxc and disks.

The Problem:
Everything which uses disk access especially with fsync is very very slow.
Emerging large packages freezes the system during unpack.
Disk IO stops blocks all other IO even when the Desktop does not freeze. (Network Streams, Audio Output)

A postgres DB restore can take hours with fsync on and minutes with fsync turned off in postgres itself.

I am not sure what the problem source could be. My Ideas revolve around:
* Is it LXC in general?
* Did I miss something in the kernel config?
* Is my disk setup to slow?

I am usure how to diagnose this. [Edit]What would you suggest I try to figure out the cause of the problem?[/Edit]

[khayyam]

[Reiner Lange]

It appears that part of the Problem was, that my default Scheduler was CFQ, where the Deadline Scheduler was what I needed to use.

While playing with ionice I realized, that those schedulers have very different properties and some are better suited for a Desktop Environment.

I still have to test if the slow fsyncs are caused by that as well. From my understanding of what these schedulers do it should be unoticably worse now, but not better.