On Mon, 11 Aug 2014 11:36:46 -0700 "G. Richard Bellamy" <rbell...@pteradigm.com> wrote:
> I've been playing with btrfs as a backing store for my KVM images. > > I've used 'chattr +C' on the directory where those images are stored. > > You can see my recipe below [1]. I've read the gotchas found here [2] > > I'm having continuing performance issues inside the Guest VM that is > created inside the btrfs subvolume, using a qcow2 format. I'm having a > hard time determining whether the issues are related to KVM or btrfs, > or if this is even a reasonable topic of discussion. > > I've seen the comments on this list saying that if I want a COW > filesystem with sparse files, that I'd be better off with ZFS. I'd > like to use an in-tree COW filesystem, but if it's just not gonna > happen yet with btrfs, I guess that's just the way it is. > > That being said, how would I determine what the root issue is? > Specifically, the qcow2 file in question seems to have increasing > fragmentation, even with the No_COW attr. First of all, why do you require a COW filesystem in the first place... if all you do is just use it in a NoCOW mode? Second, why qcow2? It can also have internal fragmentation which is unlikely to do anything good for performance. Try RAW format images; to reduce the space requirements, with the latest Qemu/KVM you can pass-through TRIM command from inside the VM guest (at least in the IDE controller mode) so that the backing filesystem will unmap areas that are no longer in use inside the VM, in effect "re-sparsifying" the image. This is VERY nifty. But yeah this can cause some fragmentation even with NoCOW. In my personal use case NoCOW is only utilized partly, because all subvolumes with running VMs are being snapshotted about every 30 minutes, and those snapshots are kept for two weeks. The performance is passable; at least when using KVM's "cache=writeback" mode (or less safer ones). -- With respect, Roman
signature.asc
Description: PGP signature
