0

I'm running a Raid5 (3x 500GB Sata2 HDD) based on btrfs 3.12 (Ubuntu 14.04 x64) and a VirutalBox VM uses this volume. As long as no other process accesses the volume, the VM runs fine. But recently I copied a larger file to that volume too and I almost got no iops out of my VM. Opening even small programs inside the VM took up to several minutes. The copy process in contrast runs on acceptable speed. Furthermore I used gzip to zip that large file on the btrfs volume and virtual box seems to have issues keeping the VM alive (vm windows turns grey, did not respond).

I found that using the mount option noatime could help to improve performance, but as I only access two files on the volume (the VM's VDI and the other file) I think this would not improve the situation much.

Could you please explain this behaviour to me and maybe suggest something to improve the VM's throughput?

Improve this question
3
  • What kernel are you using on 14.04? More recent installation come with 3.16 (from Utopic HWE). You may get better performance with the 3.16 backport (package linux-generic-lts-utopic).
    – gertvdijk
    Apr 16, 2015 at 9:39
  • I just followed your advice, but unfortunately the new kernel does not include a newer btrfs: $ btrfs --version; Btrfs v3.12; uname -a; Linux hostname 3.16.0-34-generic #47~14.04.1-Ubuntu SMP Fri Apr 10 17:49:16 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
    – Oliver R.
    Apr 16, 2015 at 11:36
  • Oh there is a lot of development in btrfs. The btrfs command line management tool is not the same as the kernel modules. :) Don't confuse the two.
    – gertvdijk
    Apr 16, 2015 at 11:39

1 Answer 1

Reset to default
3

If you have a disk image on a BTRFS volume, you might need to turn off the Copy on Write feature, at least for your VM disk image.

CoW copies altered data to a new space (with its alterations) before modifying the file header data. On a VM this means shoving a HUGE file around for even the most basic change.

You can have CoW turned off on a disk image file if you copy (not move) it to a directory on which this command was run:

chattr +C directory

However this does not guarantee No_COW, as you may create Btrfs subvolume snapshot containing the image file (that will make it cow-only-once).

Improve this answer
2
  • Thank you very much, I was not aware of this. In the meantime I've converted the RAID5 to RAID0, but even there the VM feels much more responsive. I'll now convert it back to RAID5 and check the performance again.
    – Oliver R.
    Apr 16, 2015 at 11:04
  • I'm still using it as a RAID0 volume and I can fully reproduce, even though its a hard example: When I use dd to write a file of zeros to that volume, I got a throughput of ~150MB/s. While writing those zeros I almost got no iops for the VM. The newer kernel (mentioned by askubuntu.com/users/449/oli) and chattr -C did not help very much. I furthermore checked the IO-queue for the three HDDs. It shows that they have about 150 IOs queued, but I don't know how to interpret that.
    – Oliver R.
    Apr 16, 2015 at 11:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .