Comment 8 for bug 712392

Quoting Alvin (<email address hidden>):
> Unfortunately, this shows up in both host and guests.
>
> I haven't tried to use qemu-img on a snapshot, but I will. I fear it
> will not make much difference. Just having snapshots (without accessing
> them) is enough to bring the system down on moments with heavy I/O.
>
> Sometime this week, I will warn the users of their impending doom and
> try out whether it makes a difference.

I assume you have very fast underlying storage and that's the trigger.
Rather than running qemu-img under 'nice', I wonder whether you would
be better off running qemu-img in a cgroup with tighter controls over
its blkio. I've not experimented with this myself, but
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/blkio-controller.txt;h=465351d4cf853e8a308c9c84abef789b3dcfa42c;hb=HEAD
should give some good info.

I also must point out that the only storage failures I've seen myself
(roughly a year ago) were due to ext4 itself. I since switched to
xfs for all root and data partitions and have not seen the like since.
Unfortunately that's likely not a viable option for you as you have
users already depending on the system (plus 2.6.38 is rumored to bring
its own xfs instabilities, though I've not seen those here). However
if it were possible, I'd highly recommending testing with xfs.