On 11/16/2013 06:36 PM, Cole Robinson wrote:
On 11/14/2013 03:46 PM, Gene Czarcinski wrote:
I have been experimenting with putting /var/lib/libvirt/images on a btrfs
subvolume. What I found was ... interesting.
Just doing nothing else, a disk image file can en up with something like
50,000 extents or more. Now, you can go do a btrfs fi defrag and it will
reduce but when you use the system, it will increase again.
OK, you cannot turn off "cow" for a subvolume but you can turn it off for a
new file (or more important) for an new file in a directory: chattr +C
/var/lib/libvirt/images and any new disk image file will have no-cow.
OK, install a system with a new disk file. The result: a file with 47,000
extents. The reason, I used virt-manager and the disk image file allocated
was a sparse file. Now in some respects sparse files are good because they do
not use space unless they need it. But, with BTRFS, the result is large scale
fragmentation. And, btrfs fi defrag does not
work on this file /directory.
OK, another try. Preallocate a file using dd if=/dev/zero
of=/var/lib/libvirt/images/xxx.img bs=1024 count=12587000 and the result is a
12GB (more or less) virtual disk. Install a system using this as the virtual
disk. extents=9. install a second system subvol=root2 (it is a virtual btrfs
system). extents=9. And a third one. extents=9. BTW, these installs were
about the fastest I have ever seen!
So, is there a way to do this "sparse=false" disk allocation with
virt-manager, or do I need to do an RFE?
For a system where the disk images are going to be on BTRFS, a fully allocated
disk has definite benefits.
virt-manager already has this option: in the 'new vm' wizard, there's a
checkbox for 'allocate entire disk now' or similar. it is checked by default.
But we just ask libvirt to handle this for us, and it is likely using
fallocate and not writing tons of zeros like dd will do.
Maybe libvirt should skip that fallocate step on btrfs. I've moved your bug
[1] to libvirt for further investigation.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1031303
I have been doing a lot more testing including running on Fedora 19 (my
all BTRFS system has both Fedora-20-Beta and Fedora 19 installed). With
Fedora-19 and virt-manager-0.10.0-4.fc19.noarch, the VM creation wizard
defaults the storage format defaults to raw. The result is the the disk
image file as a very low number of extents (59 under Fedora 19 but after
rebooting into Fedora-20-Beta, it was 12). Note: I am using "filefrag"
to determine the number of extents.
I also ran a test which left a very small qcow2 disk and added an 8GB
raw disk where Fedora 20 was installed.
I assume that the disk image formatting is being handed off to libvirt
for all disk images. In that case, libvirt is working properly. The
difference is qcow2 which, IIUC, is a sparse only format and raw which
can be a nonsparse file.
Nonsparse raw format files all have a very low number of extents: below
20 and most often below 10.
So, what is my problem? My "current" problem is that I cannot change
the storage format specified on the disk created by the vm creation
wizard. The current bugzilla report has become confused (my doing) and
I will be closing it and opening a new report with the problem as I now
understand it. To keep things simple, I will also be adding a new
bugzilla RFE report to ask for the ability to specify just what the
default storage format is.
Gene
_______________________________________________
virt mailing list
virt@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/virt
