Jatin Davey
2015-Jun-02 03:44 UTC
[libvirt-users] preallocation=full Vs preallocation=metadata
Hi All I was reading through this: http://kashyapc.com/2011/12/02/little-more-disk-io-perf-improvement-with-fallocateing-a-qcow2-disk/ I was basically searching for pointers on improving disk I/O. I wanted to know the purpose of preallocation=full & preallocation=metadata , What is the difference between them ? and which one would yield a better disk I/O speed ? Appreciate your responses in this regard. Thanks Jatin
Kashyap Chamarthy
2015-Jun-03 07:38 UTC
Re: [libvirt-users] preallocation=full Vs preallocation=metadata
On Tue, Jun 02, 2015 at 09:14:03AM +0530, Jatin Davey wrote:> Hi All > > I was reading through this: > > http://kashyapc.com/2011/12/02/little-more-disk-io-perf-improvement-with-fallocateing-a-qcow2-disk/In my testing, the above method gives near-raw performance as it preallocated all the space ahead of time. The above test can now be done in a single command -- see option (3) below.> I was basically searching for pointers on improving disk I/O. > > I wanted to know the purpose of preallocation=full & preallocation=metadata > > > , What is the difference between them ? and which one would yield a better > disk I/O speed ?There are three options that modern `qemu-img` supports: (1) 'preallocation=metadata': allocates qcow2 metadata, and it's still a sparse image. $ qemu-img create -f qcow2 -o preallocation=metadata test1-metadata.qcow2 1G Formatting 'test1-metadata.qcow2', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 preallocation='metadata' lazy_refcounts=off refcount_bits=16 328K -rw-r--r--. 1 root root 1.1G Jun 3 03:20 copy-test1-metadata.qcow2 (2) 'preallocation=full': allocates zeroes and makes a non-sparse image. $ qemu-img create -f qcow2 -o preallocation=full test2-full.qcow2 1G Formatting 'test2-full.qcow2', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 preallocation='full' lazy_refcounts=off refcount_bits=16 $ ls -lash test2-full.qcow2 1.1G -rw-r--r--. 1 root root 1.1G Jun 3 03:31 test2-full.qcow2 (3) 'preallocation=falloc': which uses posix_fallocate() to "allocate blocks and marking them as uninitialized", and is relatively faster than writing out zeroes to a file: $ qemu-img create -f qcow2 -o preallocation=falloc test3-falloc.qcow2 1G Formatting 'test3-falloc.qcow2', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 preallocation='falloc' lazy_refcounts=off refcount_bits=16 $ ls -lash test3-falloc.qcow2 1.1G -rw-r--r--. 1 root root 1.1G Jun 3 03:32 test3-falloc.qcow2 You can test and compare between (2) and (3) what works best for you. -- /kashyap
Jatin Davey
2015-Jun-03 12:44 UTC
Re: [libvirt-users] preallocation=full Vs preallocation=metadata
Thanks Kashyap. I will test with option 2 & 3 and use whichever gives better results. Thanks Jatin On 6/3/2015 1:08 PM, Kashyap Chamarthy wrote:> On Tue, Jun 02, 2015 at 09:14:03AM +0530, Jatin Davey wrote: >> Hi All >> >> I was reading through this: >> >> http://kashyapc.com/2011/12/02/little-more-disk-io-perf-improvement-with-fallocateing-a-qcow2-disk/ > In my testing, the above method gives near-raw performance as it > preallocated all the space ahead of time. > > The above test can now be done in a single command -- see option (3) > below. > >> I was basically searching for pointers on improving disk I/O. >> >> I wanted to know the purpose of preallocation=full & preallocation=metadata > >> >> , What is the difference between them ? and which one would yield a better >> disk I/O speed ? > There are three options that modern `qemu-img` supports: > > (1) 'preallocation=metadata': allocates qcow2 metadata, and it's still > a sparse image. > > $ qemu-img create -f qcow2 -o preallocation=metadata test1-metadata.qcow2 1G > Formatting 'test1-metadata.qcow2', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 preallocation='metadata' lazy_refcounts=off refcount_bits=16 > 328K -rw-r--r--. 1 root root 1.1G Jun 3 03:20 copy-test1-metadata.qcow2 > > (2) 'preallocation=full': allocates zeroes and makes a non-sparse image. > > $ qemu-img create -f qcow2 -o preallocation=full test2-full.qcow2 1G > Formatting 'test2-full.qcow2', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 preallocation='full' lazy_refcounts=off refcount_bits=16 > $ ls -lash test2-full.qcow2 > 1.1G -rw-r--r--. 1 root root 1.1G Jun 3 03:31 test2-full.qcow2 > > (3) 'preallocation=falloc': which uses posix_fallocate() to "allocate > blocks and marking them as uninitialized", and is relatively faster > than writing out zeroes to a file: > > $ qemu-img create -f qcow2 -o preallocation=falloc test3-falloc.qcow2 1G > Formatting 'test3-falloc.qcow2', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 preallocation='falloc' lazy_refcounts=off refcount_bits=16 > $ ls -lash test3-falloc.qcow2 > 1.1G -rw-r--r--. 1 root root 1.1G Jun 3 03:32 test3-falloc.qcow2 > > You can test and compare between (2) and (3) what works best for you. >
Apparently Analagous Threads
- Re: preallocation=full Vs preallocation=metadata
- Re: Fedora 19/20 new install :Unable to create vcpu cgroup
- Autodetecting backing file properties when using vol-create-as
- Re: [Qemu-devel] [qemu-img] support for XVA
- virt-sparsify changing the apparent-size of files