On 2014-08-14 10:30, G. Richard Bellamy wrote: > 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). The fact that it is Windows using NTFS is probably part of the problem. Here's some things you can do to decrease it's background disk utilization (these also improve performance on real hardware): 1. Disable system restore points. These aren't really necessary if you are running in a VM and can take snapshots from the host OS. 2. Disable the indexing service. This does a lot of background disk IO, and most people don't need the high speed search functionality. 3. Turn off Windows Features that you don't need. This won't help disk utilization much, but can greatly improve overall system performance. 4. Disable the paging file. Windows does a lot of unnecessary background paging, which can cause lots of unneeded disk IO. Be careful doing this however, as it may cause problems for memory hungry applications. 5. See if you can disable boot time services you don't need. Bluetooth, SmartCard, and Adaptive Screen Brightness are all things you probably don't need in a VM environment.
Of these, 1, 2, and 4 will probably help the most. The other thing is that NTFS is a journaling file system, and putting a journaled file system image on a COW backing store will always cause some degree of thrashing, because the same few hundred MB of the disk get rewritten over and over again, and the only way to work around that on BTRFS is to make the file NOCOW, AND preallocate the entire file in one operation (use the fallocate command from util-linux to do this).
smime.p7s
Description: S/MIME Cryptographic Signature
