>I don't think preallocation=metadata is required for sparse qcow2. >Just if you want it to NOT be sparse for metadata.
I think it is required. Please see the output below. Only "metadata.img" is a sparse file. ============== [root@ut1-qmb-rd5c test]# qemu-img create -f qcow2 -o preallocation=off off.img 3G Formatting 'off.img', fmt=qcow2 size=3221225472 encryption=off cluster_size=65536 preallocation='off' [root@ut1-qmb-rd5c test]# qemu-img create -f qcow2 -o preallocation=metadata metadata.img 3G Formatting 'metadata.img', fmt=qcow2 size=3221225472 encryption=off cluster_size=65536 preallocation='metadata' [root@ut1-qmb-rd5c test]# qemu-img create -f qcow2 -o preallocation=full full.img 3G Formatting 'full.img', fmt=qcow2 size=3221225472 encryption=off cluster_size=65536 preallocation='full' [root@ut1-qmb-rd5c test]# qemu-img create -f qcow2 no_option.img 3G Formatting 'no_option.img', fmt=qcow2 size=3221225472 encryption=off cluster_size=65536 [root@ut1-qmb-rd5c test]# ls -alhs total 3.1G 4.0K drwxr-xr-x 2 root root 4.0K Feb 1 06:29 . 4.0K dr-xr-x---. 5 root root 4.0K Feb 1 06:19 .. 3.1G -rw-r--r-- 1 root root 3.1G Feb 1 06:23 full.img 592K -rw-r--r-- 1 root root 3.1G Feb 1 06:21 metadata.img 136K -rw-r--r-- 1 root root 256K Feb 1 06:29 no_option.img 136K -rw-r--r-- 1 root root 256K Feb 1 06:21 off.img ============== >I also remember hearing that either recent qemu-img has a decent >preallocation by default now, or that performance has improved such >that it doesn't matter. Will need to do some reading to remember, but >I think I remember hearing it's not a big deal nowadays. Ummm. I tested with "qemu-img version 0.12.1," and I confirmed the performance of "preallocation=off" is worse than "preallocation=metadata", but it may be not true with latest qemu. I will test it. Thank you for your comment! Regards, 2014-01-31 Marcus <shadow...@gmail.com>: > I don't think preallocation=metadata is required for sparse qcow2. > Just if you want it to NOT be sparse for metadata. > > I also remember hearing that either recent qemu-img has a decent > preallocation by default now, or that performance has improved such > that it doesn't matter. Will need to do some reading to remember, but > I think I remember hearing it's not a big deal nowadays. > > On Fri, Jan 31, 2014 at 10:04 PM, Yoshikazu Nojima <m...@ynojima.net> wrote: >> Hello Nux, >> >> Thank you for your comment. I will prepare feature specification. >> >> Regards, >> >> 2014-01-31 Nux! <n...@li.nux.ro>: >>> On 31.01.2014 20:24, Yoshikazu Nojima wrote: >>>> >>>> Afternoon All, >>>> >>>> Is there anyone working on adding volume provisioning method option? >>>> As you know, thin provisioning of a volume save consumption of a >>>> storage, and fat provisioning improves IOPS performance. >>>> Especially, Qcow2 can save storage consumption and achive relatively >>>> better performance than default by provisioning a volume with an >>>> option "preallocation=metadata", which makes an image file a sparse >>>> file. >>>> >>>> http://itscblog.tamu.edu/improve-disk-io-performance-in-kvm/#.232---preallocation >>>> >>>> Any thoughts about this? >>>> If it is ok, I will write a feature specification on confluence and >>>> start implementation. >>>> >>>> Regards, >>>> Noji >>>> >>>> >>>> Yoshikazu Nojima <m...@ynojima.net> >>> >>> >>> Hello, >>> >>> I thought preallocation=metadata is common practice since years. Now I find >>> out ACS doesn't actually use it? >>> If so, this is really _bad_ and needs to be fixed ASAP... >>> >>> Thanks Noji >>> >>> -- >>> Sent from the Delta quadrant using Borg technology! >>> >>> Nux! >>> www.nux.ro
