On Wed, Aug 13, 2014 at 9:23 PM, Chris Murphy <li...@colorremedies.com> wrote: > lsattr /var/lib/libvirt/images/atlas.qcow2 > > Is the xattr actually in place on that file?
2014-08-14 07:07:36 $ filefrag /var/lib/libvirt/images/atlas.qcow2 /var/lib/libvirt/images/atlas.qcow2: 46378 extents found 2014-08-14 07:08:34 $ lsattr /var/lib/libvirt/images/atlas.qcow2 ---------------C /var/lib/libvirt/images/atlas.qcow2 So, yeah, the attribute is set. > > It will fragment somewhat but I can't say that I've seen this much > fragmentation with xattr C applied to qcow2. What's the workload? How was the > qcow2 created? I recommend -o > preallocation=metadata,compat=1.1,lazy_refcounts=on when creating it. My > workloads were rather simplistic: OS installs and reinstalls. What's the > filesystem being used in the guest that's using the qcow2 as backing? When I created the file, I definitely preallocated the metadata, but did not set compat or lazy_refcounts. However, isn't that more a function of how qemu + KVM managed the image, rather than how btrfs? This is a p2v target, if that matters. Workload has been minimal since virtualizing because I have yet to get usable performance with this configuration. The filesystem in the guest is Win7 NTFS. I have seen massive thrashing of the underlying volume during VSS operations in the guest, if that signifies. > > It might be that your workload is best suited for a preallocated raw file > that inherits +C, or even possibly an LV. I'm close to that decision. As I mentioned, I much prefer the btrfs subvolume story over lvm, so moving to raw is probably more desirable than that... however, then I run into my lack of understanding of the difference between qcow2 and raw with respect to recoverability, e.g. does raw have the same ACID characteristics as a qcow2 image, or is atomicity a completely separate concern from the format? The ability for the owning process to recover from corruption or inconsistency is a key factor in deciding whether or not to turn COW off in btrfs - if your overlying system is capable of such recovery, like a database engine or (presumably) virtualization layer, then COW isn't a necessary function from the underlying system. So, just since I started this reply, you can see the difference in fragmentation: 2014-08-14 07:25:04 $ filefrag /var/lib/libvirt/images/atlas.qcow2 /var/lib/libvirt/images/atlas.qcow2: 46461 extents found That's 17 minutes, an OS without interaction (I wasn't doing anything with it, but it may have been doing its own work like updates, etc.), and I see an fragmentation increase of 83 extents, and a raid10 volume that was beating itself up (I could hear the drives chattering away as they worked). -rb -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
