Re: Large files, nodatacow and fragmentation

[Roman Mamedov <rm@romanrm.net>]

[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]

On Mon, 11 Aug 2014 11:36:46 -0700
"G. Richard Bellamy" <rbellamy@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]