The arch wiki recommends that images have Copy-On-Write disabled on the directory when using btfs. I do see that it would be a good idea if you had a lot of file read/writes. This question explores this idea. I know that VMWare will grow into different files and will write snapshots out which could be problematic when using Copy-On-Write.
For QEMU the file is left open for the VMs existance so there is a potential problem in the write after the VM is shutdown, but I would see slow I/O after a VM is shutdown not being an issue. What pitfalls would I be avoiding by performing this step for QEMU.
Additionally:
I have assumed that the image is raw for this question. Is there a possible stability issue as qcow2 already has copy-on write.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
The performance degradation with VM images on BTRFS is not merely due to a lot of file writes; as far as BTRFS is concerned the writes are to the same file. The issue arises from a lot of random writes to the same file. These are writes which occur throughout the file.
In a nutshell, random writes interfere with BTRFS’ COW resulting in file fragmentation, which in turn causes read performance degradation. If you have an image file on hand, you can check for file fragmentation with filefrag.
Note this is not an issue with just VM images. It affects any file written to at random file offsets, such as the SQLite databases used by Firefox.
Solutions/work-arounds
There are a few things you can do about file fragmentation on BTRFS. Choose one of the following:
- Mount the filesystem with
nodatacow, which disables COW through the entire filesystem. Although really, it avoids using COW unless it absolutely has to (such as creating a snapshot). - Use
chattrto disable COW on the directory containing the files in question, and then recreate the files since thechattrdoesn’t apply to existing files. - Periodically run
btrfs fi defragagainst the files in question. - Mount the filesystem with
autodefragto automatically defrag the filesystem.
The first two options disables COW while the last two allows COW but cleans things up after-the-fact. The BTRFS COW and the QEMU COW should not interfere, it’d just be extra slow 🙂
My personal experience
In my experience with SQLite database files …
nodatacow– Haven’t tried it.chattr– I ended up with fragmented files anyway.btrfs fi defrag– I did this for a while to test the concept.autodefrag– I’ve been using this quite successfully.
For QEMU images, I use LVM volumes instead of image files. So I don’t deal with the COW issue at all.
Resources
Recommended reading to get a better sense of how COW works on BTRFS.
- https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
- https://btrfs.wiki.kernel.org/index.php/FAQ#Can_copy-on-write_be_turned_off_for_data_blocks.3F
- https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_on_Write_.28CoW.29
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0